CockroachDB (분산 SQL 데이터베이스)

1. 서론: 분산 SQL의 새로운 패러다임, CockroachDB

1.1 현대 애플리케이션의 요구사항과 전통적 데이터베이스의 한계

클라우드 네이티브 환경의 보편화와 마이크로서비스 아키텍처로의 전환은 데이터베이스 기술에 근본적인 변화를 요구한다. 과거의 모놀리식 애플리케이션과 달리, 현대의 분산 애플리케이션은 전 세계 사용자를 대상으로 상시 가동되어야 하며, 예측 불가능한 트래픽 변동에 유연하게 대응해야 한다. 이러한 환경은 데이터베이스에 수평적 확장성(horizontal scalability), 지리적 분산(geo-distribution), 그리고 상시 가용성(always-on availability)이라는 새로운 차원의 요구사항을 제시하였다.1

전통적인 단일 노드 관계형 데이터베이스 관리 시스템(RDBMS), 예를 들어 PostgreSQL과 같은 시스템들은 데이터 일관성과 무결성을 보장하는 데 탁월한 성능을 보여주었다. 그러나 이들의 아키텍처는 근본적으로 단일 서버의 성능에 의존하는 수직적 확장(vertical scaling, scaling up)에 최적화되어 있다. 시스템의 용량을 늘리기 위해 더 강력한 하드웨어로 교체하는 방식은 물리적, 비용적 한계에 빠르게 도달한다. 수평적 확장(horizontal scaling, scaling out)을 시도하기 위해서는 애플리케이션 레벨에서 복잡한 수동 샤딩(manual sharding)을 구현해야만 했다. 이 과정은 막대한 운영 복잡성을 야기할 뿐만 아니라, 여러 샤드에 걸친 트랜잭션 처리의 어려움과 데이터 불일치 위험을 급격히 증가시키는 원인이 되었다.3

이러한 RDBMS의 한계를 극복하기 위해 등장한 NoSQL 데이터베이스는 뛰어난 수평적 확장성과 높은 가용성을 제공하며 분산 시스템의 요구에 부응했다. 하지만 이러한 장점을 얻는 과정에서 관계형 모델이 제공하는 스키마의 엄격성, 풍부한 쿼리 기능, 그리고 무엇보다 중요한 강력한 트랜잭션 일관성(ACID 보장)을 희생하는 경우가 많았다.1 이로 인해 개발자들은 확장성과 일관성 사이에서 어려운 기술적 타협을 해야만 했다.

이러한 기술적 딜레마 속에서 분산 SQL(Distributed SQL) 또는 NewSQL이라는 새로운 패러다임이 부상했다. 분산 SQL의 핵심 목표는 RDBMS의 강점인 강력한 일관성, ACID 트랜잭션, 친숙한 SQL 인터페이스를 유지하면서, 동시에 NoSQL의 장점인 수평적 확장성, 내결함성, 지리적 분산 능력을 통합하는 것이다.1 CockroachDB는 이러한 분산 SQL의 비전을 가장 충실하게 구현한 대표적인 데이터베이스 시스템 중 하나이다.

1.2 CockroachDB의 핵심 가치 제안

CockroachDB는 공식적으로 “트랜잭션 및 강력한 일관성을 보장하는 Key-Value 저장소 위에 구축된 분산 SQL 데이터베이스“로 정의된다.7 이 정의는 시스템의 근본적인 설계 철학을 담고 있으며, 그 핵심 가치 제안은 다음 세 가지 축으로 명확하게 요약될 수 있다.

첫째, **노력 없는 확장성(Effortless Scale)**이다. CockroachDB는 복잡하고 오류 발생 가능성이 높은 수동 샤딩 작업을 완전히 제거했다. 대신, 클러스터에 새로운 노드를 추가하는 것만으로 데이터베이스의 저장 용량과 트랜잭션 처리 용량이 거의 선형적으로 증가한다. 시스템은 새로 추가된 노드를 자동으로 감지하고, 기존 데이터를 재배치하여 클러스터 전체의 부하를 균등하게 분산시킨다.3

둘째, **강력한 복원력(Bulletproof Resilience)**이다. 시스템의 이름인 ’바퀴벌레(Cockroach)’는 그 어떤 재난에서도 살아남는 극강의 생존력을 상징한다.10 CockroachDB는 데이터를 여러 노드에 걸쳐 자동으로 복제함으로써 단일 디스크, 머신, 랙(rack)의 장애는 물론, 데이터센터 전체 또는 지리적 리전(region) 단위의 대규모 장애 상황에서도 최소한의 서비스 중단과 데이터 손실 없이 운영을 지속할 수 있도록 설계되었다. 모든 복구 과정은 운영자의 수동 개입 없이 자동으로 이루어진다.7

셋째, **지리적 분산(Geo-distribution)**이다. CockroachDB는 클러스터를 여러 지리적 위치에 걸쳐 구성하고, 테이블의 행(row) 단위까지 데이터의 물리적 저장 위치를 정교하게 제어할 수 있는 기능을 제공한다. 이를 통해 데이터를 최종 사용자와 가까운 곳에 배치하여 애플리케이션의 응답 지연 시간을 획기적으로 줄일 수 있다. 또한, GDPR과 같은 데이터 주권(data sovereignty) 규정을 준수하기 위해 특정 국가나 지역 내에 데이터를 국한시켜야 하는 요구사항을 데이터베이스 수준에서 충족시킬 수 있다.3

이 세 가지 핵심 가치는 서로 유기적으로 결합하여, 개발자와 운영자가 분산 시스템의 복잡성을 직접 다루지 않고도 확장 가능하고, 항상 가용하며, 전 세계적으로 일관된 애플리케이션을 구축할 수 있도록 지원한다. 이는 애플리케이션 아키텍처의 복잡성을 데이터베이스 계층으로 이전하려는 근본적인 패러다임의 전환을 의미한다. 과거 개발자들은 확장성을 위해 애플리케이션 코드 내에서 샤딩 로직을 구현하거나, NoSQL 데이터베이스의 최종 일관성 문제를 해결하기 위해 복잡한 데이터 보정 로직을 작성해야 했다.14 이러한 작업은 개발 비용을 증가시키고 시스템의 취약성을 높이는 주요 원인이었다. CockroachDB는 “데이터베이스가 분산 시스템의 복잡성을 처리해야 한다“는 철학을 바탕으로, 자동 리밸런싱, 분산 트랜잭션, 지리적 데이터 배치와 같은 기능들을 통해 애플리케이션의 부담을 덜어준다. 따라서 CockroachDB의 도입은 단순히 데이터베이스 기술을 교체하는 것을 넘어, 애플리케이션 아키텍처 전체를 단순화하고 개발자가 비즈니스 로직 구현에 더 집중할 수 있도록 만드는 전략적 결정으로 이어진다.

1.3 데이터베이스 시장에서의 위치와 Google Spanner와의 관계

CockroachDB의 설계는 Google이 내부적으로 사용하기 위해 개발한 전 지구적 분산 데이터베이스인 Spanner와, 그 위에 구축된 관계형 데이터베이스 서비스인 F1 기술에서 깊은 영감을 받았다.8 Spanner는 분산 트랜잭션의 외부 일관성(external consistency)을 보장하기 위해 GPS 수신기와 원자 시계를 결합한 TrueTime API라는 독점적인 하드웨어에 의존한다. 이는 트랜잭션 타임스탬프의 불확실성을 나노초 단위로 줄여 분산 합의 과정을 크게 단순화하는 혁신적인 접근법이었다.

그러나 이러한 하드웨어 의존성은 Spanner가 Google Cloud Platform(GCP) 환경 밖에서는 구동될 수 없다는 본질적인 제약을 낳았다. CockroachDB는 Spanner의 강력한 일관성 모델과 확장성 개념을 계승하면서도, 이러한 하드웨어 종속성을 해결하는 것을 중요한 설계 목표로 삼았다. 그 결과, CockroachDB는 범용 하드웨어와 표준 네트워크 환경에서도 동작할 수 있도록 소프트웨어 기반의 시간 동기화 메커니즘인 하이브리드 논리 시계(Hybrid Logical Clock, HLC)를 독자적으로 구현했다.16

이러한 아키텍처적 차이는 CockroachDB에 엄청난 전략적 유연성을 부여했다. Spanner가 GCP라는 단일 클라우드 생태계에 묶여 있는 반면, CockroachDB는 AWS, Azure, GCP 등 모든 주요 퍼블릭 클라우드는 물론, 온프레미스 데이터센터나 이들을 혼합한 하이브리드 클라우드 환경에도 자유롭게 배포할 수 있다.18 이러한 ’클라우드 중립성(cloud-neutral)’은 특정 벤더에 대한 종속(vendor lock-in)을 피하고자 하는 기업들에게 매우 매력적인 요소로 작용한다. 따라서 CockroachDB는 데이터베이스 시장에서 Spanner의 사상적 후계자이자, 동시에 Spanner가 접근할 수 없는 더 넓은 시장을 공략하는 경쟁자로서 독자적인 위치를 점하고 있다.

2. CockroachDB 핵심 아키텍처 심층 분석

CockroachDB의 아키텍처는 분산 시스템의 복잡성을 체계적으로 관리하고, 각 기능이 독립적으로 발전하면서도 전체 시스템이 유기적으로 동작할 수 있도록 여러 개의 논리적 계층으로 구성된다. 이 계층적 설계의 진정한 혁신은 ’Range’라는 단일 추상화를 통해 확장성, 복원력, 트랜잭션 일관성이라는, 때로는 상충될 수 있는 세 가지 목표를 동시에 달성했다는 점에 있다. Range는 물리적 데이터 분할(샤딩), 논리적 복제 그룹(Raft), 트랜잭션 조정 단위(Leaseholder)의 역할을 모두 수행하는 ’만능 빌딩 블록’으로서 CockroachDB 아키텍처의 근간을 이룬다.

전통적인 분산 데이터베이스 시스템에서는 샤딩, 복제, 트랜잭션 관리가 종종 별개의 메커니즘과 운영 도구를 필요로 했다. 예를 들어, 샤딩은 미들웨어가, 복제는 스트리밍 복제 방식이, 트랜잭션은 2단계 커밋(2PC) 프로토콜이 각각 담당하는 식이었다. 이는 시스템을 복잡하게 만들고 각 메커니즘 간의 상호작용에서 예측하기 어려운 문제가 발생할 소지를 남겼다. CockroachDB는 이 모든 핵심 분산 기능을 ’Range’라는 일관된 개념으로 통합했다. 데이터가 일정 크기를 넘으면 Range가 분할되면서 자동으로 샤딩(수평 확장)이 이루어지고 9, 각 Range는 Raft 그룹이 되어 데이터 복제와 고가용성을 보장하며 20, 각 Range에는 Leaseholder가 존재하여 읽기 성능을 최적화하고 쓰기 연산을 조정한다.21

이 통합된 접근 방식 덕분에, 노드가 추가되면 시스템은 단순히 Range들을 새로운 노드로 ’이동’시키기만 하면 리밸런싱이 완료되고 22, 노드가 실패하면 해당 노드에 있던 Range들의 복제본을 다른 노드에 ’재생성’하면 자동 복구가 이루어진다.22 결과적으로, Range라는 잘 정의된 추상화 계층 덕분에 상위 계층(SQL, Transactional)은 데이터의 물리적 위치나 복제 상태를 신경 쓸 필요 없이 단일 논리 데이터베이스처럼 동작할 수 있으며, 하위 계층(Replication, Storage)은 복잡한 분산 문제를 독립적인 Range 단위로 단순화하여 처리할 수 있다. 이것이 CockroachDB가 운영의 단순성을 유지하면서 복잡한 분산 기능을 안정적으로 제공할 수 있는 핵심 비결이다.

2.1 5계층 아키텍처(Layered Architecture)

CockroachDB는 복잡성을 관리하기 위해 잘 정의된 5개의 계층으로 구성된 아키텍처를 채택했다. 각 계층은 바로 위아래 계층과 API를 통해 상호작용하며, 다른 계층의 내부 구현에 대해서는 알 필요가 없는 블랙박스처럼 동작한다. 이는 각 계층의 독립적인 개발과 유지보수를 용이하게 한다.23

1. SQL 계층 (SQL Layer): 최상위 계층으로, 클라이언트 애플리케이션과의 상호작용을 담당한다. PostgreSQL 와이어 프로토콜과 호환되어 다양한 언어의 드라이버, ORM, GUI 도구들이 별도의 수정 없이 연결될 수 있다.9 이 계층은 클라이언트로부터 수신한 SQL 쿼리를 파싱하고, 비용 기반 옵티마이저(Cost-Based Optimizer)를 통해 최적의 실행 계획을 수립한 후, 이를 하위 계층이 이해할 수 있는 Key-Value(KV) 연산으로 변환하는 역할을 한다.23 클러스터의 모든 노드는 대칭적으로 동작하여 어떤 노드든 SQL 게이트웨이 역할을 수행할 수 있으므로, 로드 밸런서와의 통합이 용이하다.24
2. 트랜잭션 계층 (Transactional Layer): 분산 환경에서 ACID(원자성, 일관성, 고립성, 지속성) 시맨틱을 보장하는 트랜잭션을 구현하는 핵심 계층이다. 여러 KV 항목에 대한 변경 작업을 하나의 원자적 단위로 묶어, 전부 성공하거나 전부 실패하도록 보장한다.23 이 계층은 동시성 제어, 트랜잭션 격리 수준(기본적으로 SERIALIZABLE) 관리, 그리고 분산 커밋 프로토콜을 처리하여 데이터의 정합성을 유지한다.24
3. 분산 계층 (Distribution Layer): 단일하고 거대한 논리적 Key-Value 공간을 물리적으로 여러 노드에 분산시키는 역할을 한다. 이 계층은 전체 KV 공간을 ’Range’라는 관리 가능한 단위로 분할하고, 각 Range의 위치와 복제본 정보를 메타데이터로 관리한다. SQL 계층으로부터 전달받은 KV 연산 요청에 대해, 해당 키가 속한 Range를 찾아 그 Range의 복제본을 가진 적절한 노드로 요청을 라우팅한다.23 이를 통해 상위 계층은 데이터의 물리적 위치를 전혀 인지할 필요 없이 단일 데이터베이스처럼 상호작용할 수 있다.
4. 복제 계층 (Replication Layer): 데이터의 내결함성(fault tolerance)과 고가용성(high availability)을 보장하는 계층이다. 분산 계층에 의해 관리되는 각 Range에 대해, 이 계층은 여러 노드에 걸쳐 복제본(replica)을 생성하고 유지한다. 데이터 변경(쓰기) 요청이 발생하면, Raft 합의 알고리즘을 사용하여 해당 Range의 복제본 과반수가 변경에 동의해야만 커밋을 허용한다. 이를 통해 일부 노드에 장애가 발생하더라도 데이터의 손실 없이 일관성을 유지할 수 있다.23 또한 일관된 읽기(consistent read)를 가능하게 하는 메커니즘도 이 계층에서 제공된다.
5. 저장소 계층 (Storage Layer): 가장 하위 계층으로, Key-Value 데이터를 실제 디스크에 쓰고 읽는 역할을 담당한다. CockroachDB는 RocksDB를 기반으로 Go 언어로 재작성한 Pebble이라는 고성능 임베디드 KV 저장소 엔진을 사용한다.20 이 계층은 MVCC(Multi-Version Concurrency Control)를 구현하기 위해 모든 데이터에 타임스탬프 기반 버전을 부여하여 저장한다. 이를 통해 특정 시점의 데이터를 조회하는 ‘Time-Travel’ 쿼리(AS OF SYSTEM TIME)가 가능해진다.24

2.2 데이터 분할 및 관리 단위: ‘Range’

CockroachDB에서 데이터 관리의 가장 기본적인 단위는 ’Range’이다. 시스템 내의 모든 사용자 데이터(테이블, 인덱스)와 대부분의 메타데이터는 논리적으로 하나의 거대한, 키(key)에 의해 정렬된 맵(sorted map)에 Key-Value 쌍으로 저장된다.9 이 거대한 논리적 맵은 물리적으로 관리하기 쉽도록 ’Range’라고 불리는 연속적인 키 공간의 조각들로 분할된다.

초기 클러스터는 전체 키 공간을 포괄하는 단 하나의 비어있는 Range로 시작한다. 데이터가 삽입됨에 따라 이 Range의 크기는 점차 증가한다. Range의 크기가 시스템에 설정된 임계값(기본적으로 64MB)에 도달하면, 해당 Range는 키 공간의 중간 지점을 기준으로 두 개의 새로운 Range로 자동으로 분할(split)된다.8 이 과정은 데이터가 계속 추가됨에 따라 재귀적으로 반복된다. 반대로, 데이터 삭제로 인해 Range의 크기가 너무 작아지면, 시스템은 운영 효율성을 위해 인접한 Range와 병합(merge)할 수도 있다.20

이 64MB라는 크기는 신중하게 선택된 값이다. 데이터를 복구하거나 클러스터 내에서 리밸런싱을 수행할 때 노드 간에 신속하게 이동시키기에 충분히 작으면서도, 관련된 데이터를 함께 묶어 디스크 I/O 효율성을 유지하기에 충분히 큰 절충점이다.9

Range는 단순히 데이터 분할의 단위를 넘어선다. 이것은 복제(replication), 리밸런싱(rebalancing), 그리고 분산 트랜잭션 처리의 기본 단위이기도 하다. 즉, CockroachDB의 모든 핵심적인 분산 메커니즘은 Range를 중심으로 동작한다. 이 일관된 추상화 덕분에 시스템은 복잡한 분산 환경을 수많은 독립적인 작은 문제들로 나누어 효과적으로 관리할 수 있다.20

2.3 합의와 복제: Raft 합의 알고리즘과 ‘Leaseholder’

데이터의 일관성과 내결함성을 보장하기 위해, 각 Range는 여러 노드에 걸쳐 복제된다. 기본적으로 모든 Range는 3개의 복제본(replica)을 가지며, 각 복제본은 서로 다른 노드(이상적으로는 서로 다른 물리적 랙이나 가용 영역)에 위치한다. 이 복제본들의 집합은 하나의 Raft 그룹을 형성한다.8 Raft는 Paxos 알고리즘의 대안으로 널리 알려진 합의 알고리즘으로, 분산 시스템에서 여러 노드가 데이터 상태에 대해 일관된 합의를 이룰 수 있도록 하는 프로토콜이다.

데이터에 대한 모든 쓰기 요청은 해당 데이터가 속한 Range의 Raft 그룹 리더(Leader)에게 전달된다. 리더는 이 요청을 로그 항목으로 만들어 다른 팔로워(follower) 복제본들에게 전파한다. 과반수(quorum)의 복제본, 예를 들어 3개 중 2개의 복제본이 이 로그 항목을 자신의 디스크에 안전하게 기록했다고 리더에게 응답하면, 리더는 해당 쓰기 요청을 커밋(commit)하고 클라이언트에게 성공을 알린다. 이 합의 과정을 통해, 과반수의 노드가 살아있는 한 데이터는 안전하게 보존되고 일관성이 유지된다.8

모든 요청을 Raft 합의 과정을 거치게 하면 쓰기 지연 시간이 길어질 수 있으며, 특히 읽기 요청의 경우 성능 저하가 심각할 수 있다. CockroachDB는 이 문제를 해결하기 위해 ’Leaseholder’라는 독창적인 메커니즘을 도입했다. Leaseholder는 특정 시간 동안(lease 기간) 해당 Range에 대한 모든 읽기 및 쓰기 요청을 조정할 독점적인 권한을 가진 복제본이다.20

Leaseholder는 항상 해당 Range의 Raft 리더와 동일한 노드에 위치하도록 관리된다. 쓰기 요청은 여전히 Raft 합의를 위해 Leaseholder(이자 Raft 리더)를 거쳐야 하지만, 읽기 요청은 Leaseholder에서 직접 처리될 수 있다. Leaseholder는 자신이 lease를 보유하고 있는 동안 다른 노드에서 해당 Range에 대한 쓰기가 발생하지 않음을 보장받기 때문에, Raft 합의 과정 없이도 로컬 저장소에서 직접 최신 데이터를 읽어 클라이언트에게 반환할 수 있다. 이 최적화는 읽기 지연 시간을 크게 단축시키며, 읽기 중심의 워크로드에서 CockroachDB가 높은 성능을 발휘할 수 있게 하는 핵심적인 요소이다.21

3. 분산 환경에서의 트랜잭션과 일관성 보장 메커니즘

CockroachDB의 일관성 모델은 ’시간(Time)’을 분산 시스템의 핵심 제어 변수로 사용하는 정교한 공학적 절충의 산물이다. Google Spanner가 TrueTime API를 통해 트랜잭션 타임스탬프에 대한 거의 절대적인 ’확신’을 가지는 반면, CockroachDB는 하이브리드 논리 시계(HLC)를 통해 ’불확실성(uncertainty)’을 가진 물리적 시간을 분산 합의의 기반으로 삼는다. Spanner의 접근법이 하드웨어의 힘으로 문제를 단순화한다면, CockroachDB는 이 불확실성을 정면으로 인정하고 이를 소프트웨어적으로 관리하기 위한 복잡하지만 실용적인 메커니즘을 구축했다.

두 노드의 물리적 시계는 max_offset 만큼 차이가 날 수 있으므로 27, HLC 타임스탬프 ts_1 < ts_2라고 해서 이벤트 1이 이벤트 2보다 반드시 먼저 발생했다고 단정할 수 없다. 이 ’불확실성 간격(uncertainty interval)’이 존재하며, CockroachDB의 트랜잭션 시스템은 이 간격 내에서 발생할 수 있는 잠재적 충돌을 감지하고 해결하도록 설계되었다. 쓰기 인텐트(write intents)와 타임스탬프 캐시(timestamp cache)는 이러한 잠재적 충돌을 감지하는 센서 역할을 한다.28 예를 들어, 트랜잭션 T1이 키 K를 읽은 후, T1의 타임스탬프 불확실성 간격 내에 있는 더 이른 타임스탬프를 가진 T2가 K에 쓰려고 하면 RW(Read-Write) 충돌이 발생한다. 이 경우, 시스템은 직렬화 가능성을 보장하기 위해 둘 중 하나의 트랜잭션을 중단시키고 재시도하도록 강제한다.29

결론적으로 CockroachDB의 트랜잭션 시스템은 “일단 낙관적으로 진행하고(optimistic), 충돌이 발생하면 시간을 재조정하여 해결한다“는 원칙에 따라 작동한다. HLC는 이벤트 순서의 ’초안’을 제공하고, 트랜잭션 계층은 이 초안이 직렬화 가능성이라는 엄격한 규칙을 위반하지 않는지 ’검증’하며, 위반 시 ‘수정’(재시도)하는 역할을 한다. 이는 값비싼 하드웨어 제약을 극복하고 순수 소프트웨어만으로 Spanner 수준의 강력한 일관성을 제공하려는 야심 찬 설계의 결과물이다.

3.1 분산 ACID 트랜잭션의 구현: ‘Parallel Commits’ 프로토콜

CockroachDB는 지리적으로 멀리 떨어진 노드들에 걸쳐 데이터를 수정하는 경우에도 완전한 ACID 시맨틱을 보장한다.30 분산 트랜잭션을 원자적으로 커밋하기 위해 널리 알려진 고전적인 방법은 2단계 커밋(2-Phase Commit, 2PC) 프로토콜이다. 2PC는 먼저 모든 참여 노드에게 트랜잭션을 커밋할 준비가 되었는지 묻고(1단계: Prepare), 모든 노드로부터 긍정적인 응답을 받으면 최종적으로 커밋 명령을 내리는(2단계: Commit) 방식으로 동작한다. 그러나 이 방식은 코디네이터와 참여 노드 간에 최소 두 번의 네트워크 왕복(round-trip)을 필요로 하므로, 특히 노드 간 지연 시간이 큰 광역 네트워크(WAN) 환경에서는 커밋 지연 시간이 길어지는 심각한 단점이 있다.

이 문제를 해결하기 위해 CockroachDB는 ’Parallel Commits’라는 최적화된 원자적 커밋 프로토콜을 개발했다.32 이 프로토콜의 핵심 아이디어는 2PC의 두 단계를 효과적으로 병렬화하여 네트워크 왕복 횟수를 줄이는 것이다. 트랜잭션 커밋 요청이 발생하면, 트랜잭션 코디네이터는 트랜잭션 레코드의 상태를 PENDING에서 STAGING으로 즉시 변경하고, 이 STAGING 상태의 트랜잭션 레코드와 모든 쓰기 인텐트(write intent)의 복제 요청을 모든 관련 Raft 그룹에 동시에, 병렬적으로 전송한다.

클라이언트는 모든 쓰기 인텐트가 각 Raft 그룹의 과반수에 성공적으로 복제되었다는 확인을 받으면 즉시 트랜잭션이 커밋된 것으로 간주하고 다음 작업을 시작할 수 있다. 트랜잭션 레코드의 상태를 최종적으로 COMMITTED로 변경하는 작업은 백그라운드에서 비동기적으로 처리된다. 만약 다른 트랜잭션이 STAGING 상태의 쓰기 인텐트를 발견하면, 해당 트랜잭션은 잠시 기다리지 않고 직접 트랜잭션 레코드를 COMMITTED 상태로 변경하여 커밋 과정을 완료시킬 수 있다. 이처럼 커밋 결정과 실제 데이터 복제를 병렬로 처리함으로써, Parallel Commits는 특히 멀티 리전 환경에서 트랜잭션 커밋에 필요한 시간을 크게 단축시킨다.33

3.2 직렬화 가능(Serializable) 격리 수준의 구현 원리

CockroachDB는 기본적으로 SQL 표준에서 정의한 가장 강력한 격리 수준인 SERIALIZABLE을 제공한다.30 이는 여러 트랜잭션이 동시에 실행되더라도, 그 최종 결과는 마치 모든 트랜잭션이 어떠한 순서에 따라 하나씩 순차적으로 실행된 것과 동일함을 보장하는 수준이다. 이를 통해 더 낮은 격리 수준에서 발생할 수 있는 더티 리드(dirty read), 반복 불가능한 읽기(non-repeatable read), 팬텀 리드(phantom read), 쓰기 스큐(write skew) 등 모든 종류의 동시성 이상 현상(anomaly)을 원천적으로 방지한다.35

이 강력한 보장을 구현하기 위해 CockroachDB는 MVCC(Multi-Version Concurrency Control)와 타임스탬프 순서 지정, 그리고 쓰기 인텐트(write intents)와 트랜잭션 레코드(transaction record)라는 핵심 개념을 결합한다.

• 쓰기 인텐트(Write Intents): 트랜잭션이 특정 키의 값을 수정하려고 할 때, 기존 값을 즉시 덮어쓰는 대신 ’쓰기 인텐트’라는 임시적인 레코드를 해당 키에 생성한다. 이 인텐트에는 새로운 값과 함께, 이 쓰기를 시도하는 트랜잭션의 ID와 타임스탬프가 기록된다. 이 인텐트는 해당 트랜잭션이 최종적으로 커밋되거나 중단될 때까지 일종의 잠금(lock) 역할을 수행하며, 다른 트랜잭션이 동일한 키에 접근하는 것을 제어한다.29

• 트랜잭션 레코드(Transaction Record): 각 트랜잭션은 자신의 상태(PENDING, COMMITTED, ABORTED)를 기록하는 중앙 저장소인 ’트랜잭션 레코드’를 가진다. 트랜잭션의 첫 번째 쓰기 작업 시 생성되며, 모든 쓰기 인텐트는 자신의 트랜잭션 레코드를 가리킨다. 다른 트랜잭션이 쓰기 인텐트를 발견하면, 해당 인텐트가 가리키는 트랜잭션 레코드를 조회하여 트랜잭션의 현재 상태를 확인하고 그에 따라 동작한다 (예: COMMITTED 상태이면 인텐트를 최종 값으로 적용하고, ABORTED 상태이면 인텐트를 무시한다).29

• 충돌 해결(Contention Handling): 두 개 이상의 트랜잭션이 동일한 데이터에 동시에 접근하려고 할 때 충돌(contention)이 발생한다. CockroachDB는 기본적으로 낙관적 동시성 제어(optimistic concurrency control) 방식을 사용한다.37 즉, 트랜잭션들은 일단 충돌이 없을 것이라 가정하고 작업을 진행하다가, 쓰기 인텐트를 생성하거나 데이터를 읽는 과정에서 다른 트랜잭션과의 충돌이 감지되면 이를 해결한다. 충돌 해결은 각 트랜잭션에 할당된 타임스탬프와 우선순위(priority)에 기반한다. 일반적으로 타임스탬프가 더 늦거나 우선순위가 낮은 트랜잭션이 중단(abort)되고, 클라이언트에게 재시도 오류(

40001)를 반환한다. 애플리케이션은 이 오류를 수신하면 전체 트랜잭션을 처음부터 다시 시작해야 한다. 이러한 클라이언트 측 재시도 로직은 CockroachDB를 사용하는 애플리케이션 개발에서 필수적인 부분이다.30

경합이 매우 심한 워크로드의 경우, 이러한 낙관적 접근 방식은 잦은 재시도를 유발하여 성능을 저하시킬 수 있다. 이러한 시나리오를 위해 CockroachDB는 SELECT... FOR UPDATE 구문을 제공한다. 이 구문은 트랜잭션이 특정 행을 읽을 때 다른 트랜잭션이 해당 행을 수정하거나 잠그지 못하도록 배타적 잠금(exclusive lock)을 획득하게 한다. 이를 통해 잠재적인 충돌을 사전에 방지하고 트랜잭션 재시도 횟수를 줄여, 경합이 심한 워크로드의 처리량과 응답 시간을 개선할 수 있다.39

3.3 시간과 순서의 동기화: 하이브리드 논리 시계(HLC)

분산 시스템에서 물리적으로 떨어져 있는 노드들 간에 ’시간’과 ’이벤트의 순서’를 일관되게 정의하는 것은 매우 어려운 문제이다. Google Spanner는 이 문제를 해결하기 위해 원자 시계와 GPS에 의존하는 TrueTime API를 사용하지만, 이는 범용 하드웨어에서는 사용할 수 없는 해결책이다. CockroachDB는 이 제약을 극복하기 위해 순수 소프트웨어 기반의 하이브리드 논리 시계(Hybrid Logical Clock, HLC)를 구현했다.16

HLC는 두 가지 구성 요소로 이루어진 타임스탬프를 생성한다: 물리적 구성 요소와 논리적 구성 요소이다.

1. 물리적 구성 요소 (Physical Component): 각 노드의 시스템 시계(wall time)를 기반으로 하며, NTP(Network Time Protocol)를 통해 주기적으로 동기화된다. 이는 타임스탬프가 실제 시간과 너무 멀리 벗어나지 않도록 보장한다.41
2. 논리적 구성 요소 (Logical Component): 동일한 물리적 시간 내에서 발생하는 여러 이벤트를 구별하기 위한 단조 증가(monotonically increasing) 카운터이다. 만약 두 이벤트의 물리적 시간이 같다면, 논리적 카운터 값이 더 큰 이벤트가 나중에 발생한 것으로 간주된다.41

HLC 타임스탬프는 (physical_time, logical_counter) 형태의 튜플로 표현된다. 노드에서 새로운 이벤트(예: 트랜잭션 시작)가 발생하면, 노드는 자신의 현재 물리적 시간과 내부 논리적 카운터를 사용하여 새로운 HLC 타임스탬프를 생성한다. 노드가 다른 노드로부터 메시지(예: RPC 요청)를 수신할 때, 메시지에 포함된 HLC 타임스탬프를 자신의 HLC와 비교한다. 만약 수신한 타임스탬프가 자신의 것보다 미래의 시간이라면, 자신의 물리적 시계를 수신한 타임스탬프의 물리적 시간으로 ’점프’시킨다. 이는 시스템 전체의 시간이 단조롭게 증가하도록 보장하고, 메시지 전송과 수신 사이의 인과 관계(causality)를 타임스탬프에 반영하는 효과를 가진다 (e hb f ⇒ hlc(e) < hlc(f)).40

이 HLC 타임스탬프는 CockroachDB의 모든 트랜잭션과 모든 데이터 버전에 할당된다. 이를 통해 MVCC를 구현하고, 어떤 트랜잭션이 어떤 데이터 버전을 볼 수 있는지를 결정하며, 궁극적으로 트랜잭션들의 직렬화 가능 순서를 정의하는 핵심적인 기준으로 사용된다.37

그러나 NTP 기반의 시간 동기화는 완벽하지 않으며, 노드 간에 약간의 시계 오차(clock skew)가 존재할 수밖에 없다. CockroachDB는 max_offset이라는 설정값(기본 500ms)을 통해 허용 가능한 최대 시계 오차를 정의한다. 만약 어떤 노드가 클러스터 내 다른 노드들의 과반수와 비교하여 자신의 시계가 이 max_offset의 80% 이상 차이 나는 것을 감지하면, 데이터 일관성을 심각하게 훼손할 위험이 있다고 판단하여 스스로 프로세스를 종료시킨다. 따라서 프로덕션 환경에서는 모든 노드에서 NTP 클라이언트를 실행하여 시계 오차를 최소한으로 유지하는 것이 매우 중요하다.27

4. 수평적 확장성과 무중단 고가용성 구현

CockroachDB의 아키텍처는 ’모든 노드는 동등하다(all nodes are created equal)’는 대칭적(symmetrical) 철학에 깊이 뿌리내리고 있다. 이는 시스템 내에 특별한 역할을 수행하는 마스터 노드나 코디네이터 노드가 존재하지 않음을 의미하며, 단일 장애점(Single Point of Failure, SPOF)을 원천적으로 제거하는 설계이다.44 많은 전통적인 분산 시스템이 마스터/슬레이브 구조를 가지며, 이 경우 마스터 노드의 장애는 복잡한 페일오버 절차를 유발하고 전체 시스템의 가용성에 심각한 위협이 된다.15

CockroachDB에서는 모든 노드가 SQL 게이트웨이 역할을 수행할 수 있고, 모든 노드가 데이터(Range)의 Leaseholder가 될 수 있다.23 클러스터의 상태 정보는 중앙 집중식 메타데이터 저장소가 아닌, 가십 프로토콜을 통해 모든 노드에 분산되어 공유된다.8 이러한 대칭성 덕분에 어떤 노드에 장애가 발생하더라도 나머지 노드들이 즉시 그 역할을 대신할 수 있다. Leaseholder 이전, Raft 리더 재선출, 복제본 재생성과 같은 모든 복구 과정은 분산된 각 Range 그룹 내에서 자율적으로 일어난다.

마찬가지로, 클러스터에 새로운 노드를 추가하는 것은 단순히 시스템에 또 다른 ’동등한 일꾼’을 추가하는 것과 같다. 기존 노드들은 가십 프로토콜을 통해 새로운 노드의 존재를 인지하고, 자신들이 가진 부하(Range)의 일부를 자발적으로 새로운 노드에게 나누어 줌으로써 시스템 전체의 균형을 맞춘다.9 이 근본적인 ‘대칭성’ 원칙은 CockroachDB의 운영 단순성과 강력한 복원력의 원천이다. 운영자는 복잡한 장애 시나리오나 확장 계획을 수립할 필요 없이, 시스템이 스스로 최적의 상태를 유지하도록 신뢰할 수 있게 된다.

4.1 자동 리밸런싱 및 장애 복구(Self-Healing) 메커니즘

CockroachDB의 핵심적인 운영상의 장점 중 하나는 클러스터의 상태 변화에 자동으로 적응하는 능력이다. 이는 자동 리밸런싱과 자동 장애 복구(self-healing) 메커니즘을 통해 구현된다.

• 자동 리밸런싱(Automated Rebalancing): 클러스터에 새로운 노드가 추가되거나 기존 노드가 제거될 때, CockroachDB는 데이터와 처리 부하를 클러스터 전체에 균등하게 재분배하기 위해 자동으로 리밸런싱을 수행한다. 이 과정은 운영자의 개입 없이 이루어진다.9 리밸런싱 결정은 각 노드가 가십 프로토콜(gossip protocol)을 통해 주기적으로 교환하는 정보, 예를 들어 각 노드의 디스크 사용량, CPU 부하, 그리고 보유하고 있는 Range의 수 등을 기반으로 한다.8 각 노드는 클러스터 전체의 평균 Range 수와 자신의 Range 수를 비교하여, 자신이 평균보다 많은 Range를 보유하고 있다면 일부 Range의 복제본을 더 여유 있는 다른 노드로 이전하려는 결정을 자율적으로 내린다.22 이 메커니즘은 클러스터의 자원이 항상 최적으로 활용되도록 보장한다.
• 장애 감지 및 자동 복구(Failure Detection & Self-Healing): 노드에 하드웨어 장애가 발생하거나 네트워크 연결이 끊기는 등의 문제가 발생하면, 해당 노드는 다른 노드와의 하트비트(heartbeat) 통신에 실패하게 된다. 일정 시간(기본적으로 5분) 동안 노드로부터 응답이 없으면, 클러스터의 다른 노드들은 해당 노드를 ‘의심스러운(suspect)’ 상태를 거쳐 최종적으로 ‘죽은(dead)’ 상태로 판단한다.22

노드가 ’dead’로 선언되면, CockroachDB는 자동 복구, 즉 ‘자가 치유(self-healing)’ 프로세스를 시작한다.46 죽은 노드가 보유하고 있던 모든 Range 복제본들은 이제 ‘부족하게 복제된(under-replicated)’ 상태가 된다. 예를 들어 복제 계수가 3인 Range는 이제 2개의 복제본만 가지게 된다. 이를 감지한 해당 Range의 Raft 리더(Leaseholder)는 즉시 클러스터 내의 다른 건강한 노드에 새로운 복제본을 생성하도록 지시한다. 새로운 복제본이 생성되고 기존 복제본들과 동기화가 완료되면, Range는 다시 완전하게 복제된 상태(fully-replicated)가 되어 원래의 내결함성 수준을 회복한다. 이 모든 과정은 완전히 자동화되어 있어, 운영자는 장애 발생 사실을 인지하지 못할 수도 있다.22

4.2 다양한 장애 시나리오 대응

CockroachDB의 분산 아키텍처와 자동 복구 메커니즘은 다양한 수준의 장애 시나리오를 견딜 수 있도록 설계되었다.

• 노드 장애(Node Failure): 가장 기본적인 장애 시나리오이다. 기본 복제 계수인 3을 사용하는 클러스터에서는, 하나의 노드가 실패하더라도 모든 Range는 여전히 3개 중 2개의 복제본, 즉 과반수(quorum)를 유지한다. 따라서 Raft 합의가 계속 가능하며, 읽기 및 쓰기 작업은 중단 없이 계속 처리될 수 있다. 실패한 노드의 Leaseholder 역할은 몇 초 내에 다른 복제본으로 이전된다.47
• 가용 영역 장애(Availability Zone Failure): 클라우드 환경에서 흔히 고려되는 장애 시나리오이다. 데이터센터 내의 독립적인 전원 및 네트워크를 갖춘 구역인 가용 영역(AZ) 전체에 장애가 발생할 수 있다. 이를 대비하기 위해, 프로덕션 클러스터는 최소 3개 이상의 서로 다른 AZ에 노드를 분산하여 배포하는 것이 권장된다. 이렇게 구성하면, 하나의 AZ 전체가 다운되더라도 나머지 2개의 AZ에 있는 노드들이 과반수 복제본을 유지하여 클러스터 전체의 가용성을 보장할 수 있다.21
• 리전 장애(Region Failure): 지진, 허리케인과 같은 자연재해나 대규모 네트워크 장애로 인해 지리적으로 격리된 리전 전체가 마비될 수 있다. 이러한 최악의 시나리오에 대비하기 위해, CockroachDB 클러스터를 3개 이상의 리전에 걸쳐 배포할 수 있다. 데이터의 복제 범위를 리전 단위로 설정하면, 하나의 리전이 완전히 고립되거나 파괴되더라도 다른 리전의 노드들이 서비스를 계속 이어갈 수 있다.3

견딜 수 있는 동시 장애의 수는 복제 계수(Replication Factor)에 따라 결정된다. 장애 허용 노드 수의 공식은 (Replication factor - 1) / 2이다. 예를 들어, 복제 계수를 5로 설정하면 (5−1)/2=2, 즉 2개의 노드가 동시에 실패해도 시스템은 정상 작동한다.47

4.3 다운타임 없는 롤링 업그레이드의 원리 및 절차

데이터베이스 시스템의 업그레이드는 전통적으로 서비스 중단(downtime)을 동반하는 고위험 작업이었다. 그러나 CockroachDB의 ‘다중 활성 가용성(multi-active availability)’ 아키텍처는 클러스터 전체를 중단시키지 않고 한 번에 한 노드씩 순차적으로 업그레이드하는 ’롤링 업그레이드(rolling upgrade)’를 가능하게 한다.3

롤링 업그레이드의 원리는 고가용성 메커니즘과 동일하다. 업그레이드를 위해 하나의 노드를 잠시 중단시키더라도, 클러스터의 나머지 노드들은 여전히 과반수 복제본을 유지하며 정상적으로 서비스를 처리할 수 있다. 업그레이드되는 노드는 일시적인 장애 상태와 동일하게 취급된다.44

롤링 업그레이드의 절차는 다음과 같다 50:

1. 클러스터의 노드 중 하나를 선택하여 로드 밸런서에서 제외시킨 후, cockroach quit 명령을 사용하여 정상적으로 종료시킨다.
2. 해당 노드의 서버에서 기존 CockroachDB 바이너리 파일을 새로운 버전의 바이너리로 교체한다. 컨테이너 환경이라면 도커 이미지를 새 버전으로 업데이트한다.
3. 업데이트된 바이너리로 노드를 재시작한다. 노드는 클러스터에 다시 참여하고, 중단되었던 동안 발생한 변경 사항들을 다른 노드로부터 동기화하여 최신 상태를 따라잡는다.
4. 노드가 완전히 재가동되고 안정화되었음을 확인한 후, 다시 로드 밸런서에 추가하여 트래픽을 받기 시작한다.
5. 클러스터의 모든 노드에 대해 1~4단계를 순차적으로 반복한다.

모든 노드의 업그레이드가 완료되면 클러스터 전체가 새로운 버전으로 운영된다. 특히 메이저 버전 업그레이드의 경우, 모든 노드가 새 버전으로 전환된 후에도 한동안 이전 버전과의 호환성 모드로 동작한다. 이 기간 동안에는 문제가 발생할 경우 이전 버전으로 롤백할 수 있다. 운영자가 새로운 버전이 안정적이라고 판단하면, ‘finalization’ 명령을 실행하여 업그레이드 절차를 최종적으로 완료한다. Finalization이 완료되면 새로운 기능들이 완전히 활성화되며, 더 이상 이전 버전으로의 롤백은 불가능해진다. 이 finalization 과정은 cluster.auto_upgrade.enabled 설정을 통해 자동으로 수행되도록 구성할 수도 있다.50

5. 지리적 분산 및 데이터 지역성 최적화 전략

CockroachDB의 지리적 분산 기능은 단순한 데이터 복제를 넘어, ‘데이터 중력(data gravity)’ 문제를 소프트웨어 정의(software-defined) 방식으로 해결하려는 정교한 시도이다. 전통적으로 데이터의 물리적 위치는 데이터센터나 클라우드 리전 선택과 같은 인프라 수준에서 한 번 결정되면 변경하기 어려웠고, 다른 지역에서의 데이터 접근은 필연적으로 높은 네트워크 지연 시간을 감수해야 했다.

CockroachDB는 --locality 시작 플래그, 복제 영역 설정(zone configurations), 그리고 테이블 지역성(table localities) 설정과 같은 여러 계층의 제어 기능을 제공함으로써 이 문제를 해결한다.21 이러한 기능들은 개발자와 아키텍트가 물리적 세계의 제약(네트워크 지연 시간)과 비즈니스의 논리적 요구사항(규정 준수, 성능 목표) 사이에서 정교한 트레이드오프를 할 수 있게 해준다. 예를 들어, REGIONAL BY ROW 설정은 “A 사용자의 데이터는 미국 동부에, B 사용자의 데이터는 서유럽에 저장하되, 이 모든 데이터는 논리적으로 users라는 단일 테이블에 속하게 하라“는 복잡한 요구사항을 단 하나의 SQL 구문으로 해결한다.52

이는 데이터베이스가 더 이상 수동적인 데이터 저장소가 아님을 의미한다. CockroachDB는 데이터의 물리적 위치를 동적으로 최적화하고, 쿼리 실행 계획을 수립할 때 데이터의 지역성을 핵심 요소로 고려하며, 장애 발생 시 자동으로 데이터를 재배치한다. 결과적으로, CockroachDB는 데이터베이스 관리의 패러다임을 ’서버 관리’에서 ’데이터 흐름 및 정책 관리’로 전환시킨다. 개발자와 운영자는 ALTER TABLE과 같은 친숙한 SQL 인터페이스를 사용하여 글로벌 데이터 패브릭(global data fabric)을 제어하게 되며, 이는 분산 시스템 운영의 복잡성을 극적으로 낮추는 혁신적인 접근법이다.

5.1 멀티 리전 토폴로지 패턴 분석

글로벌 서비스를 구축할 때, 모든 사용자가 동일한 수준의 성능과 가용성을 경험하도록 하는 것은 매우 어렵다. CockroachDB는 애플리케이션의 특정 요구사항, 즉 ’지연 시간(latency)을 얼마나 낮추고 싶은가’와 ’어떤 종류의 장애를 견디고 싶은가(resilience)’라는 두 가지 핵심 질문에 답하기 위해 다양한 멀티 리전 토폴로지 패턴을 제공한다.21

• Follow-the-Workload: 이 패턴은 CockroachDB의 기본 동작 방식이다. 데이터(Range)의 복제본들은 여러 리전에 분산되어 리전 장애에 대한 복원력을 제공한다. 동시에, 시스템은 읽기 요청이 집중되는 리전을 동적으로 감지하여 해당 Range의 Leaseholder를 그 리전으로 이동시킨다. 이를 통해 해당 리전의 사용자들은 로컬에서 데이터를 읽는 것과 같은 낮은 지연 시간을 경험할 수 있다. 쓰기 요청은 여전히 Raft 합의를 위해 여러 리전으로 전파되어야 하므로 지연 시간이 발생하지만, 읽기 중심의 워크로드에 매우 효과적이다. 이 패턴은 하나의 리전 전체가 다운되는 장애를 견딜 수 있다.21
• Geo-Partitioned Replicas: 이 패턴은 지연 시간 최적화를 극대화하는 전략이다. 특정 데이터(예: 특정 지역 사용자의 데이터)와 관련된 모든 복제본(기본 3개)을 해당 지역 내의 노드들에 고정(pinning)시킨다. 이렇게 하면 해당 지역 내에서의 읽기와 쓰기 요청 모두가 리전 간 네트워크를 거치지 않고 처리되므로 매우 낮은 지연 시간을 달성할 수 있다. 이는 데이터 주권(data sovereignty) 요구사항을 충족시키는 데에도 가장 확실한 방법이다. 그러나 이 패턴의 명백한 단점은 복원력이다. 만약 해당 리전 전체에 장애가 발생하면, 데이터의 모든 복제본에 접근할 수 없게 되어 해당 데이터는 일시적으로 사용 불가능 상태가 된다.21
• Geo-Partitioned Leaseholders: 이 패턴은 위 두 패턴의 장점을 절충한 하이브리드 전략이다. Geo-Partitioned Replicas 패턴처럼 데이터 파티션의 Leaseholder를 특정 리전에 고정하여 해당 지역에서의 읽기 지연 시간을 최소화한다. 하지만 나머지 복제본들은 다른 리전에 분산시켜 저장한다. 이 구성에서 로컬 읽기는 Leaseholder를 통해 빠르게 처리된다. 반면, 쓰기 요청은 Raft 합의를 위해 다른 리전에 있는 복제본들과 통신해야 하므로 리전 간 지연 시간이 발생한다. 이 패턴의 가장 큰 장점은 복원력이다. Leaseholder가 있는 리전에 장애가 발생하더라도, 시스템은 다른 리전에 있는 복제본 중 하나를 새로운 Leaseholder로 즉시 선출하여 서비스를 계속 이어나갈 수 있다.21

5.2 데이터 주권 및 지연 시간 감소를 위한 지오-파티셔닝(Geo-Partitioning)

지오-파티셔닝(Geo-Partitioning)은 테이블의 데이터를 행(row) 수준에서 특정 지리적 위치와 연결하여 저장 위치를 명시적으로 제어하는 강력한 기능이다.13 이는 두 가지 주요 목적을 달성하기 위해 사용된다: 지연 시간 감소와 규정 준수.

• 지연 시간 감소: 사용자와 데이터 사이의 물리적 거리는 네트워크 지연 시간의 가장 큰 원인이다. 지오-파티셔닝을 사용하면 미국 사용자의 데이터는 미국 내 데이터센터에, 유럽 사용자의 데이터는 유럽 내 데이터센터에 저장할 수 있다. 이를 통해 사용자는 항상 가장 가까운 데이터센터와 통신하게 되어 애플리케이션의 응답 속도를 크게 향상시킬 수 있다.13
• 규정 준수: 유럽 연합의 GDPR과 같이, 특정 국가나 지역의 시민 데이터를 해당 지역 내에서만 저장하고 처리하도록 요구하는 데이터 주권 규정이 점점 더 강화되고 있다. 지오-파티셔닝은 이러한 규정을 준수하기 위한 효과적인 기술적 해결책을 제공한다. 특정 파티션의 데이터를 특정 리전에 고정함으로써, 데이터가 규정된 지리적 경계를 벗어나지 않도록 보장할 수 있다.54

지오-파티셔닝은 일반적으로 다음 세 단계로 구현된다 51:

1. 노드 지역성 설정: 클러스터를 시작할 때 각 노드에 --locality 플래그를 사용하여 리전, 가용 영역 등의 위치 정보를 태그한다.
2. 파티션 정의: CREATE TABLE 또는 ALTER TABLE 문에서 PARTITION BY 구문을 사용하여 테이블을 파티셔닝한다. 예를 들어, country 열의 값을 기준으로 ‘US’, ‘EU’, ‘APAC’ 등의 파티션을 정의할 수 있다.
3. 복제 영역 설정 적용: ALTER PARTITION... CONFIGURE ZONE 명령을 사용하여 각 파티션에 대한 복제 정책을 정의한다. 예를 들어, ‘EU’ 파티션의 모든 복제본은 region=eu-west-1 지역성 태그를 가진 노드에만 위치하도록 강제할 수 있다.

5.3 테이블 지역성(Table Locality) 설정 비교

지오-파티셔닝이 행 수준의 정교한 제어를 제공하는 반면, 테이블 지역성(Table Locality) 설정은 멀티 리전 데이터베이스에서 테이블 전체의 데이터 접근 패턴을 최적화하기 위한 더 높은 수준의 추상화를 제공한다. 개발자는 복잡한 파티셔닝 및 영역 설정을 직접 다루는 대신, 간단한 SQL 구문으로 테이블의 동작 방식을 선언할 수 있다.52

• REGIONAL: 이 설정은 테이블의 모든 데이터가 특정 ’홈 리전(home region)’에서 가장 빠른 읽기/쓰기 성능을 갖도록 최적화한다. 기본적으로 데이터베이스를 생성할 때 지정한 주 리전(primary region)이 모든 테이블의 홈 리전이 된다. 대부분의 데이터 접근이 단일 지역에서 발생하는 일반적인 애플리케이션에 가장 적합한 기본 설정이다.52
• REGIONAL BY ROW: 이 설정은 테이블의 각 행이 자신만의 홈 리전을 가질 수 있도록 한다. crdb_region이라는 숨겨진 열이 테이블에 추가되며, 행이 삽입될 때 해당 요청을 처리한 게이트웨이 노드의 리전 값이 이 열에 자동으로 기록된다. 시스템은 이 crdb_region 열을 기준으로 테이블을 자동으로 파티셔닝하고 각 파티션을 해당 리전에 배치한다. 이는 전 세계에 사용자가 분포된 글로벌 애플리케이션(예: 소셜 미디어, 사용자 프로필 관리)에서 각 사용자의 데이터를 해당 사용자와 가장 가까운 리전에 저장하여 지연 시간을 최적화하는 데 이상적이다.52
• GLOBAL: 이 설정은 모든 리전에서 빠른 읽기 성능을 제공하도록 테이블을 최적화한다. 이를 위해 데이터의 복제본을 모든 리전에 배치하고, Leaseholder를 여러 리전에 분산시키는 등의 내부적인 최적화를 수행한다. 모든 리전에서 빠른 읽기가 가능한 대신, 쓰기 요청은 모든 리전에 걸쳐 데이터를 동기화해야 하므로 높은 지연 시간을 감수해야 한다. 이를 위해 GLOBAL 테이블의 쓰기는 미래의 타임스탬프를 사용하는 특별한 논블로킹(non-blocking) 트랜잭션 프로토콜을 사용한다. 이 설정은 제품 카탈로그, 국가 코드, 시스템 설정과 같이 자주 변경되지 않지만 모든 지역에서 빠르게 조회되어야 하는 참조 데이터(reference data)에 적합하다.52

이러한 테이블 지역성 설정은 개발자가 멀티 리전 데이터베이스의 복잡한 물리적 구현을 신경 쓰지 않고도, 애플리케이션의 논리적 요구사항에 따라 데이터 접근 패턴을 손쉽게 최적화할 수 있도록 돕는다.

5.3.1 테이블 1: 테이블 지역성 설정별 특징 및 사용 사례

6. PostgreSQL 호환성: 범위와 한계

CockroachDB의 PostgreSQL 호환성은 단순한 기술적 선택을 넘어, 세계에서 가장 성숙하고 방대한 개발자 생태계를 즉시 활용하기 위한 핵심적인 비즈니스 전략이다. 새로운 데이터베이스 기술이 시장에 진입할 때 겪는 가장 큰 장벽 중 하나는 생태계, 즉 사용 가능한 드라이버, ORM, 관리 도구, 그리고 개발자들의 기존 지식 풀의 부재이다. Cockroach Labs는 PostgreSQL 와이어 프로토콜을 구현함으로써 이 문제를 단번에 해결했다.55 개발자들은 이미 익숙한 프로그래밍 언어와 프레임워크를 거의 그대로 사용하여 CockroachDB에 연결하고 상호작용할 수 있으며, 이는 학습 곡선과 초기 도입 장벽을 극적으로 낮추는 효과를 가져온다.

그러나 ’호환성’이라는 단어는 종종 완벽한 복제를 의미하는 것으로 오해될 수 있다. CockroachDB는 PostgreSQL의 소스 코드를 포크(fork)하여 분산 기능을 추가한 것이 아니라, 분산 환경의 고유한 특성에 최적화되도록 SQL 계층을 처음부터 다시 작성했다.56 이 ’재해석’과 ’재작성’의 과정에서, 분산 시스템의 근본적인 제약과 자연스럽게 부합하지 않는 일부 기능들, 예를 들어 전역적인 순차 ID 생성을 가정하는 시퀀스(sequence)나 단일 노드에서의 원자적 실행을 전제로 하는 트리거(trigger) 같은 기능들은 의도적으로 배제되거나 다른 방식으로 구현되었다.

Integer division의 동작 차이와 같은 사소해 보이는 부분조차 분산 Key-Value 저장소에서 타입을 처리하는 방식의 근본적인 차이를 반영한다.57

따라서 사용자는 CockroachDB를 “분산 환경을 위해 재설계된 PostgreSQL“로 이해하고 접근해야 한다. 모든 기능이 1:1로 동일하게 동작할 것이라는 가정은 피해야 하며, 마이그레이션 시에는 MOLT와 같은 전문 도구를 사용하여 잠재적인 비호환성을 사전에 식별하는 것이 중요하다. 또한, 분산 시스템의 고유한 특성인 네트워크 지연 시간과 트랜잭션 재시도 가능성을 애플리케이션 레벨에서 적절히 처리할 준비가 되어 있어야 성공적인 도입이 가능하다.

6.1 와이어 프로토콜, SQL 구문, 데이터 타입 호환성 분석

CockroachDB의 PostgreSQL 호환성은 여러 계층에 걸쳐 이루어진다.

• 와이어 프로토콜(Wire Protocol): 가장 기본적인 수준의 호환성으로, CockroachDB는 PostgreSQL 와이어 프로토콜(pgwire) 버전 3.0을 완벽하게 지원한다.57 이는 클라이언트 애플리케이션과 데이터베이스 서버 간의 통신 규약을 의미한다. 이 덕분에 PostgreSQL을 위해 개발된 거의 모든 데이터베이스 드라이버(JDBC, Npgsql, psycopg2 등)와 ORM 프레임워크, GUI 관리 도구(DBeaver, DataGrip 등)가 CockroachDB에 별도의 수정 없이 연결하여 기본적인 작업을 수행할 수 있다.7

• SQL 구문(SQL Syntax): CockroachDB는 SQL 쿼리를 파싱하는 데 PostgreSQL의 파서를 재사용하고 확장했기 때문에, 표준 SQL 구문뿐만 아니라 PostgreSQL 고유의 확장 구문에 대해서도 매우 높은 호환성을 보인다.55

CREATE TABLE, SELECT, INSERT, UPDATE, DELETE와 같은 기본적인 DML, DDL은 물론, UPSERT (PostgreSQL의 INSERT... ON CONFLICT와 유사), WINDOW 함수, COMMON TABLE EXPRESSIONS (CTE) 등 고급 SQL 기능 대부분을 지원한다.58

• 데이터 타입(Data Types): CockroachDB는 PostgreSQL의 주요 데이터 타입을 대부분 지원한다. INT, DECIMAL, STRING, TIMESTAMP, BOOLEAN과 같은 표준 타입은 물론, ARRAY, JSONB, UUID, INET 등 PostgreSQL의 유용한 확장 타입들도 지원 목록에 포함된다.58 그러나 일부 타입은 내부적인 표현 방식이나 이름에 차이가 있을 수 있다. 예를 들어, PostgreSQL의 VARCHAR, CHAR, TEXT는 모두 CockroachDB의 STRING 타입에 해당한다.59 또한, 정수 타입의 경우 PostgreSQL은 INT2(16비트), INT4(32비트), INT8(64비트)로 명확히 구분되는 반면, CockroachDB의 INT는 기본적으로 64비트 정수(INT8)이며, INT2, INT4 등은 호환성을 위한 별칭(alias)으로 존재하여 실제 저장 방식에 차이가 있을 수 있다.60

6.2 지원 및 미지원 PostgreSQL 기능 상세 목록

CockroachDB의 PostgreSQL 호환성은 완벽하지 않으며, 특히 분산 환경에서 구현하기 어렵거나 성능상 불리한 일부 기능들은 지원되지 않거나 다르게 동작한다.

• 지원되는 주요 고급 기능:
• 인덱스: B-Tree 인덱스 외에도 GIN(Generalized Inverted Index), Trigram 인덱스, 부분 인덱스(Partial Indexes), 표현식 기반 인덱스(Expression Indexes), 공간 인덱스(Spatial Indexes) 등 다양한 고급 인덱싱 기능을 지원하여 복잡한 쿼리 성능을 최적화할 수 있다.58
• 시스템 카탈로그: PostgreSQL과의 도구 호환성을 위해 pg_catalog 스키마를 제공한다. 이를 통해 많은 서드파티 도구들이 데이터베이스의 메타데이터(테이블, 컬럼, 인덱스 정보 등)를 조회할 수 있다. 다만, pg_catalog의 모든 뷰와 테이블이 구현되어 있지는 않다.58
• 기타: SELECT... FOR UPDATE를 통한 행 수준 잠금, ENUM 타입, ALTER TABLE을 통한 온라인 스키마 변경 등 개발자들이 자주 사용하는 많은 기능이 지원된다.58
• 미지원 또는 부분적으로 지원되는 기능:
• 트리거(Triggers) 및 이벤트(Events): 단일 노드를 가정하고 설계된 트리거는 분산 환경에서 원자적으로 실행하고 상태를 관리하기 매우 복잡하기 때문에 지원되지 않는다. 대안으로 변경 데이터 캡처(Change Data Capture, CDC) 기능을 사용하여 데이터 변경에 대한 반응을 구현하는 것이 권장된다.57
• 사용자 정의 함수(User-Defined Functions, UDFs): 오랫동안 지원되지 않았으나, 최근 베타 버전부터 제한적으로 지원되기 시작했다. 아직 안정 버전에서는 완전한 기능을 제공하지 않는다.63
• 일부 시스템 기능 및 절차적 언어: pg_advisory_lock과 같은 전역 잠금 함수나 PL/pgSQL의 모든 기능이 지원되지는 않는다.
• 해시 인덱스(Hash Indexes): 지원되지 않는다.58
• 동일 구문, 다른 동작:
• 정수 나눗셈(Integer Division): PostgreSQL에서 SELECT 5 / 2;는 정수 2를 반환하지만, CockroachDB에서는 DECIMAL 타입인 2.5를 반환한다. PostgreSQL과 동일한 정수 나눗셈 결과를 얻으려면 // 연산자(SELECT 5 // 2;)를 사용해야 한다.57
• 연산자 우선순위: 비트 NOT 연산자인 ~의 우선순위가 PostgreSQL과 달라, ~1 + 2와 같은 표현식이 다르게 해석될 수 있다.57

6.2.1 테이블 2: PostgreSQL 기능 호환성 매트릭스

6.3 PostgreSQL 생태계 활용: 드라이버, ORM, 서드파티 도구

PostgreSQL 와이어 프로토콜 호환성 덕분에, CockroachDB는 방대하고 성숙한 PostgreSQL 생태계를 그대로 활용할 수 있다. Cockroach Labs는 주요 드라이버와 ORM 프레임워크에 대해 공식적인 지원을 보장하고, 호환성 유지를 위해 지속적으로 테스트를 수행한다.64

• 드라이버(Drivers): 거의 모든 주요 프로그래밍 언어에 대한 표준 PostgreSQL 드라이버가 CockroachDB와 함께 사용될 수 있다. Cockroach Labs는 Python의 psycopg3 및 psycopg2, Node.js의 pg, Java의 JDBC, Go의 pgx,.NET의 Npgsql, Ruby의 pg 드라이버 등에 대해 ‘Full’ 또는 ‘Partial’ 수준의 지원을 공식적으로 제공한다.64
• ORM(Object-Relational Mapping) 프레임워크: 현대 애플리케이션 개발에서 널리 사용되는 ORM 프레임워크와의 원활한 통합은 매우 중요하다. CockroachDB는 Python의 SQLAlchemy와 Django, Node.js/TypeScript의 Sequelize, TypeORM, Prisma, Java의 Hibernate, Go의 GORM, Ruby의 ActiveRecord 등 주요 ORM에 대해 공식 지원을 제공한다. 일부 ORM의 경우, CockroachDB의 분산 트랜잭션 재시도 로직을 더 쉽게 처리하거나 미묘한 SQL 방언 차이를 해결하기 위한 전용 어댑터 패키지(예: sqlalchemy-cockroachdb, django-cockroachdb)를 함께 제공하기도 한다.64
• 서드파티 도구(Third-Party Tools): 데이터베이스 관리, 시각화, BI(Business Intelligence)를 위한 다양한 서드파티 도구들이 CockroachDB와 함께 사용될 수 있다. Cockroach Labs는 오픈소스 GUI 도구인 DBeaver에 대해 공식 지원을 제공한다. 이 외에도 JetBrains의 DataGrip, TablePlus, Beekeeper Studio 등 커뮤니티에서 테스트되고 널리 사용되는 여러 GUI 클라이언트가 있다.66 CData와 같은 회사는 CockroachDB용 JDBC 및 ODBC 드라이버를 제공하여, PostgreSQL FDW(Foreign Data Wrapper)를 통해 CockroachDB 데이터를 PostgreSQL 데이터베이스인 것처럼 조회하는 등 고급 통합 시나리오를 가능하게 한다.67

6.4 MOLT(Migration Toolkit)를 이용한 마이그레이션 전략

기존 데이터베이스에서 CockroachDB로 이전하는 과정을 지원하기 위해, Cockroach Labs는 MOLT(Migration Toolkit)라는 포괄적인 도구 모음을 제공한다.56 MOLT는 마이그레이션의 전체 수명 주기를 단순화하고 자동화하는 것을 목표로 한다.

• MOLT Schema Conversion Tool: 마이그레이션의 첫 단계는 스키마 변환이다. 이 도구는 PostgreSQL, MySQL, Oracle, Microsoft SQL Server와 같은 소스 데이터베이스의 스키마 정의 파일(.sql)을 분석하여 CockroachDB와 호환되는 DDL(Data Definition Language)로 자동 변환한다. 이 과정에서 잠재적인 비호환성(예: 미지원 데이터 타입, 제약 조건)을 식별하고, 수정이 필요한 부분에 대해 경고나 제안을 제공한다. 사용자는 웹 기반 UI를 통해 변환된 스키마를 검토하고 직접 수정할 수 있다.69
• MOLT Fetch: 스키마 마이그레이션이 완료되면, 실제 데이터를 이전해야 한다. MOLT Fetch는 소스 데이터베이스에서 데이터를 추출하여 CockroachDB로 로드하는 역할을 한다. 초기 데이터의 대량 적재(bulk load)뿐만 아니라, 애플리케이션의 다운타임을 최소화하기 위해 초기 적재 이후 발생하는 변경 사항을 지속적으로 복제하는 CDC(Change Data Capture) 기능도 지원한다.56
• MOLT Verify: 데이터 마이그레이션에서 가장 중요하고 어려운 부분 중 하나는 데이터 정합성을 검증하는 것이다. MOLT Verify는 이 문제를 해결하기 위해 설계된 강력한 데이터 유효성 검사 도구이다.70 마이그레이션이 완료된 후, 이 도구는 소스 데이터베이스와 타겟 CockroachDB 클러스터에 동시에 연결하여 테이블 스키마와 모든 행의 데이터를 비교한다. 누락된 행, 불일치하는 값, 추가된 행 등을 식별하여 상세한 안내서를 생성함으로써, 운영자가 데이터 손실이나 손상 없이 마이그레이션이 성공적으로 완료되었음을 확신할 수 있게 해준다. 이 검증 과정은 수십억 개의 레코드에 대해서도 확장 가능하도록 설계되었다.70

7. 배포 모델 및 운영 전략

CockroachDB의 배포 옵션은 ’제어권과 운영 부담 간의 스펙트럼’을 제공하는 것으로 이해할 수 있다. 스펙트럼의 한쪽 끝에는 개발자 경험을 극대화하기 위해 제어권을 최대한 추상화한 CockroachDB Cloud의 Serverless(현 Basic) 플랜이 있다. 이는 데이터베이스를 하나의 API 엔드포인트처럼 취급하게 해주며, 용량 계획, 스케일링, 백업 등 모든 복잡한 운영 작업을 자동화한다.71 개발자는 인프라에 대한 걱정 없이 애플리케이션 로직에만 집중할 수 있지만, 하드웨어 선택이나 세부적인 성능 튜닝과 같은 제어권은 제한된다.

스펙트럼의 다른 쪽 끝에는 최대의 제어권을 제공하지만 그에 상응하는 운영 책임을 요구하는 자체 호스팅(Self-hosted) 모델이 있다. 사용자는 운영 체제, 하드웨어, 네트워크, 보안 설정 등 인프라의 모든 측면을 직접 제어할 수 있다.73 이는 특정 규정 준수 요건을 충족하거나 기존 온프레미스 인프라에 통합해야 할 때 필수적이지만, 클럭 동기화, TLS 인증서 관리, 모니터링 시스템 구축 등 상당한 수준의 운영 전문성을 요구한다.

Kubernetes Operator는 이 두 극단 사이의 ’스위트 스팟(sweet spot)’을 공략한다. 사용자는 Kubernetes의 선언적 API(YAML 파일)를 통해 원하는 클러스터의 상태—노드 수, 버전, 리소스 등—를 ’선언’하기만 하면, Operator가 그 상태를 유지하기 위해 필요한 모든 복잡한 작업을 ‘자동으로’ 수행해준다.74 이는 Self-hosted 모델의 제어권을 상당 부분 유지하면서도 Cloud 버전의 자동화된 운영 편의성을 누릴 수 있게 해주는 강력한 모델이다.

결론적으로, 어떤 배포 모델을 선택할 것인가는 기술적 우위의 문제가 아니라, 조직의 기술적 성숙도, 운영 역량, 애플리케이션의 중요도, 비용 모델, 그리고 규제 환경에 따라 결정되는 전략적 선택이다. 스타트업은 Serverless로 빠르게 시작하고, 대기업은 Self-hosted나 Advanced 플랜으로 제어권을 확보하며, DevOps 문화가 성숙한 조직은 Kubernetes Operator를 통해 유연성과 자동화의 균형을 찾을 수 있다.

7.1 CockroachDB Cloud vs. 자체 호스팅(Self-hosted) 비교

CockroachDB는 사용자의 다양한 요구사항과 운영 능력에 맞춰 여러 배포 모델을 제공한다. 크게 Cockroach Labs가 모든 인프라 관리를 책임지는 완전 관리형 서비스인 CockroachDB Cloud와, 사용자가 직접 인프라를 구축하고 운영하는 자체 호스팅(Self-hosted) 모델로 나뉜다.75

• CockroachDB Cloud: 데이터베이스 운영의 복잡성을 제거하고 개발자가 애플리케이션 개발에 집중할 수 있도록 설계된 DBaaS(Database as a Service)이다. 백업, 패치, 업그레이드, 모니터링 등 모든 운영 작업을 Cockroach Labs의 SRE(Site Reliability Engineering) 팀이 담당한다.75 CockroachDB Cloud는 다시 워크로드 특성에 따라 세 가지 플랜으로 나뉜다.
• Basic (구 Serverless): 사용량 기반 과금 모델을 채택한 멀티 테넌트 서비스이다. 트래픽이 없을 때는 컴퓨팅 자원을 0으로 축소(scale-to-zero)하여 비용을 절감하고, 트래픽이 발생하면 자동으로 확장한다. 매월 일정량의 저장 공간과 요청 단위(Request Units, RU)를 무료로 제공하여 개발, 테스트, 또는 트래픽이 예측 불가능한 소규모 프로덕션 워크로드에 이상적이다.8
• Standard: 안정적이고 예측 가능한 워크로드를 위해 프로비저닝된 컴퓨팅 자원을 제공하는 멀티 테넌트 서비스이다. Basic 플랜보다 대규모 워크로드에서 비용 효율적일 수 있으며, 비공개 연결(private connectivity)과 같은 추가 기능을 제공한다.8
• Advanced (구 Dedicated): 미션 크리티컬 프로덕션 워크로드를 위한 싱글 테넌트 서비스이다. 고객 전용의 격리된 하드웨어 위에서 실행되므로 최고의 성능과 보안을 제공한다. VPC 피어링, 고객 관리 암호화 키(CMEK) 등 엄격한 보안 및 규정 준수 요구사항을 충족하는 고급 기능을 지원하며, 멀티 리전 배포 시 99.999%의 가용성 SLA를 보장한다.75
• 자체 호스팅(Self-hosted): 사용자가 원하는 클라우드 제공업체(AWS, GCP, Azure 등)의 가상 머신이나 자체 데이터센터의 물리적 서버에 직접 CockroachDB 클러스터를 설치하고 운영하는 모델이다. 이 모델은 데이터베이스 환경에 대한 완전한 제어권을 제공하므로, 특수한 네트워크 구성, 보안 정책, 또는 CockroachDB Cloud가 지원하지 않는 지역에 배포해야 하는 경우에 선택된다. 하지만 클러스터 프로비저닝, 구성, 모니터링, 업그레이드, 장애 대응 등 모든 운영 책임을 사용자가 직접 져야 한다.8

7.1.1 테이블 3: CockroachDB 배포 옵션 비교

7.2 쿠버네티스(Kubernetes) 환경에서의 배포 및 운영

CockroachDB는 분산 시스템으로서 컨테이너 오케스트레이션 플랫폼인 쿠버네티스와 자연스럽게 결합된다. 쿠버네티스는 상태 저장 애플리케이션(Stateful Application)을 관리하기 위한 StatefulSet이라는 리소스를 제공하며, CockroachDB는 이를 활용하여 각 노드에 안정적인 네트워크 식별자와 영구적인 스토리지를 할당받아 안정적으로 운영될 수 있다.74

쿠버네티스 환경에서 CockroachDB를 더 쉽고 안정적으로 운영하기 위해, Cockroach Labs는 CockroachDB Kubernetes Operator를 제공한다. Operator는 쿠버네티스의 핵심 패턴 중 하나로, 특정 애플리케이션에 대한 운영 지식을 코드로 자동화한 컨트롤러이다. CockroachDB Operator는 다음과 같은 복잡한 운영 작업을 자동화한다 74:

• 안전한 클러스터 배포: 몇 줄의 YAML 설정만으로 TLS 인증서 생성 및 적용을 포함한 보안 클러스터를 자동으로 배포한다.
• 간편한 스케일링: 클러스터의 노드 수를 늘리거나 줄이는 작업을 replicas 필드의 숫자를 변경하는 것만으로 간단하게 수행할 수 있다. Operator는 새로운 파드(Pod)를 생성하고, 클러스터에 안전하게 참여시키며, 데이터 리밸런싱이 완료되도록 보장한다.
• 자동화된 롤링 업그레이드: 데이터베이스 버전을 업그레이드할 때, Operator는 서비스 중단 없이 한 번에 한 파드씩 순차적으로 업그레이드를 진행하는 롤링 업그레이드 절차를 자동으로 수행한다.
• 장애 복구: 쿠버네티스 노드에 장애가 발생하여 CockroachDB 파드가 중단되면, 쿠버네티스는 자동으로 다른 노드에 파드를 재스케줄링한다. Operator는 이 과정에서 영구 볼륨(Persistent Volume)이 새로운 파드에 올바르게 다시 연결되도록 보장하여 데이터 손실 없이 노드가 클러스터에 복귀하도록 돕는다.

또한, CockroachDB Operator는 단일 쿠버네티스 클러스터를 넘어, 여러 클라우드나 리전에 걸쳐 있는 다수의 쿠버네티스 클러스터에 하나의 논리적인 CockroachDB 클러스터를 배포하고 관리하는 복잡한 멀티 클러스터 토폴로지 구성도 지원한다.78

7.3 프로덕션 환경을 위한 권장 설정 및 모니터링 베스트 프랙티스

자체 호스팅으로 CockroachDB를 프로덕션 환경에 배포할 때는 안정성, 성능, 보안을 보장하기 위해 몇 가지 핵심적인 베스트 프랙티스를 준수해야 한다.73

• 하드웨어 및 OS: glibc 기반의 최신 리눅스 배포판(Ubuntu, RHEL 등) 사용이 권장된다. 각 노드는 최소 4개의 vCPU(8개 이상 권장)와 vCPU당 4GiB의 RAM을 가져야 한다. CPU 자원을 예측 불가능하게 제한하는 ‘버스터블(burstable)’ 타입의 가상 머신은 피해야 한다. 스토리지는 vCPU당 500 IOPS 이상의 성능을 내는 SSD를 사용해야 하며, LVM 사용은 성능 저하를 유발할 수 있어 권장되지 않는다.73

• 클러스터 토폴로지: 고가용성을 위해서는 최소 3개의 노드를 서로 다른 물리적 장애 도메인(예: 3개의 다른 가용 영역)에 분산하여 배포해야 한다. 클러스터를 시작할 때 각 노드에 --locality 플래그를 사용하여 region=us-east-1,az=a와 같이 물리적 위치를 명확하게 지정해야 한다. 이는 시스템이 복제본을 지능적으로 분산 배치하는 데 필수적인 정보이다.73

• 보안: 프로덕션 클러스터는 절대 ‘insecure’ 모드로 운영해서는 안 된다. cockroach cert 명령어나 openssl을 사용하여 CA 인증서와 각 노드 및 클라이언트를 위한 TLS 인증서를 생성하고, 모든 노드 간 통신과 클라이언트-서버 통신을 암호화해야 한다. 이를 통해 중간자 공격(MITM)과 데이터 도청을 방지할 수 있다.79

• 클럭 동기화: 분산 트랜잭션의 정확성을 위해 모든 노드의 시스템 시계는 반드시 동기화되어야 한다. 모든 노드에 NTP(Network Time Protocol) 클라이언트를 설치하고 실행하여 시계 오차를 수 밀리초 이내로 유지해야 한다. 노드 간 시계 오차가 max-offset(기본 500ms)을 초과하면 데이터 일관성을 보호하기 위해 해당 노드가 자동으로 종료되므로, 클럭 동기화는 클러스터 안정성의 필수 조건이다.80

• 모니터링 및 경고: CockroachDB는 Prometheus 형식으로 수백 개의 내부 메트릭을 노출한다. 프로덕션 환경에서는 Prometheus와 Grafana, 또는 Datadog과 같은 모니터링 솔루션을 구축하여 핵심 메트릭을 지속적으로 수집하고 시각화해야 한다. 특히 모니터링해야 할 주요 지표는 다음과 같다:

• CPU 사용률: 장기간 80%를 초과하면 CPU 병목을 의심해야 한다.

• SQL 지연 시간(99th percentile): 급격한 증가는 쿼리 성능 문제를 나타낸다.

• 사용 가능한 복제본 비율(Replicas per node): 특정 노드의 복제본 수가 급감하면 노드 장애를 의미한다.

• 부족하게 복제된 Range 수(Under-replicated ranges): 0이 아닌 값이 지속되면 클러스터의 복원력에 문제가 있다는 신호이다.

• 디스크 I/O 대기열(Disk I/O queue): 지속적으로 높은 값은 스토리지 병목을 의미한다.

이러한 메트릭에 대해 합리적인 임계값을 설정하고, 임계값 초과 시 즉시 알림을 받을 수 있도록 경고 시스템을 구성하는 것이 중요하다.81

8. 주요 데이터베이스 시스템과의 비교 분석

CockroachDB의 시장 내 위치와 기술적 특성을 명확히 이해하기 위해서는 주요 데이터베이스 시스템들과의 비교 분석이 필수적이다. 이 비교는 ’일관성 스펙트럼’과 ’운영 모델’이라는 두 가지 축을 중심으로 이루어질 수 있다. 전통적인 RDBMS인 PostgreSQL과는 ’분산 vs. 중앙 집중’의 대결 구도를 형성하며, NoSQL의 대표주자인 Cassandra와는 ’강한 일관성(CP) vs. 높은 가용성(AP)’이라는 CAP 이론의 근본적인 철학적 대결을 보여준다. 한편, 동일한 분산 SQL 카테고리에 속하는 Google Spanner 및 TiDB와는 ’분산 SQL 구현 방식’에 대한 기술적, 전략적 선택의 차이를 드러낸다. 이 모든 경쟁 구도에서 CockroachDB는 ’PostgreSQL 호환성’과 ’배포 유연성(multi-cloud)’을 핵심적인 전략적 자산으로 활용하여 차별화를 꾀한다.

8.1 vs. PostgreSQL: 단일 노드 RDBMS와의 확장성 및 가용성 비교

PostgreSQL은 세계에서 가장 발전된 오픈소스 RDBMS로, 풍부한 기능과 높은 안정성으로 명성이 높다. 그러나 그 아키텍처는 근본적으로 단일 노드 환경에 최적화되어 있어, 현대적인 클라우드 애플리케이션의 요구사항인 확장성과 가용성 측면에서 본질적인 한계를 가진다.

• 확장성(Scalability): PostgreSQL의 성능을 높이는 주된 방법은 더 강력한 CPU, 더 많은 RAM, 더 빠른 디스크를 갖춘 서버로 교체하는 수직적 확장(vertical scaling)이다. 이 방식은 비용이 기하급수적으로 증가하며 물리적 한계에 부딪힌다. 수평적 확장(horizontal scaling)을 위해서는 Citus와 같은 확장을 사용하거나, 애플리케이션 레벨에서 데이터를 수동으로 분할하는 샤딩(sharding)을 구현해야 한다. 이는 운영 복잡성을 크게 증가시키고, 샤드 간 조인(join)이나 트랜잭션 처리를 매우 어렵게 만든다.15 반면, CockroachDB는 아키텍처 자체가 수평적 확장을 위해 설계되었다. 새로운 노드를 클러스터에 추가하기만 하면 데이터와 부하가 자동으로 재분배되어 시스템 전체의 용량이 선형적으로 증가한다. 이는 내장된 핵심 기능이므로 추가적인 운영 오버헤드가 거의 없다.15
• 고가용성(High Availability): PostgreSQL에서 고가용성을 확보하기 위해서는 일반적으로 액티브-패시브(Active-Passive) 또는 프라이머리-레플리카(Primary-Replica) 구조를 구성한다. 쓰기 작업은 프라이머리 노드에서만 처리되고, 이 변경 사항이 비동기적 또는 동기적 스트리밍 복제를 통해 하나 이상의 레플리카 노드로 전파된다. 프라이머리 노드에 장애가 발생하면, Patroni와 같은 외부 도구를 사용하여 레플리카 중 하나를 새로운 프라이머리로 승격시키는 페일오버(failover) 절차를 수행해야 한다. 이 과정은 수십 초에서 수 분이 소요될 수 있으며(RTO > 0), 비동기 복제를 사용하는 경우 장애 직전의 일부 트랜잭션이 유실될 수 있다(RPO > 0).15 이에 반해, CockroachDB는 다중 활성(Multi-Active) 아키텍처를 채택하고 있다. 모든 노드가 읽기 및 쓰기 요청을 처리할 수 있으며, 데이터는 Raft 합의 프로토콜을 통해 동기적으로 3개 이상의 노드에 복제된다. 노드 하나에 장애가 발생하더라도, 시스템은 서비스 중단 없이 자동으로 나머지 노드들을 통해 운영을 계속하며, RTO(복구 목표 시간)와 RPO(복구 목표 시점)를 거의 0에 가깝게 유지할 수 있다.15
• 멀티 리전 지원(Multi-Region Support): PostgreSQL을 사용하여 여러 지리적 리전에 걸쳐 쓰기 작업을 지원하는 액티브-액티브(Active-Active) 클러스터를 구축하는 것은 매우 복잡하며, 데이터 충돌 해결을 위한 정교한 외부 솔루션을 필요로 한다. 일반적으로는 단일 리전에서만 쓰기를 허용하고 다른 리전에는 읽기 전용 복제본을 두는 방식으로 제한된다.82 CockroachDB는 설계 초기부터 멀티 리전을 지원하도록 만들어졌다. 단일 논리 클러스터가 여러 리전에 걸쳐 확장될 수 있으며, 데이터 지역성 제어 기능을 통해 특정 데이터를 사용자 가까이에 배치하여 읽기/쓰기 지연 시간을 최적화하고 데이터 주권 요구사항을 충족시킬 수 있다.82

8.2. vs. Cassandra: CAP 이론 관점에서의 CP와 AP 시스템 비교

Apache Cassandra는 대규모 확장성과 극도의 고가용성을 목표로 설계된 대표적인 NoSQL 와이드 컬럼(wide-column) 데이터베이스이다. CockroachDB와 Cassandra는 모두 분산 데이터베이스라는 공통점이 있지만, CAP 이론의 관점에서 볼 때 근본적으로 다른 설계 철학을 따른다.

• CAP 이론과 일관성 모델: CAP 이론에 따르면 분산 시스템은 일관성(Consistency), 가용성(Availability), 분할 내성(Partition Tolerance) 중 최대 두 가지만을 동시에 보장할 수 있다. 네트워크 장애가 불가피한 현대 분산 환경에서는 분할 내성(P)이 필수적이므로, 시스템은 CP(일관성 우선)와 AP(가용성 우선) 사이에서 선택해야 한다.
• CockroachDB는 CP 시스템이다. Raft 합의 프로토콜을 통해 강력한 일관성을 보장한다. 네트워크 파티션으로 인해 데이터의 과반수 복제본과 통신할 수 없게 되면, 데이터의 정합성을 깨뜨릴 위험을 감수하는 대신 해당 데이터에 대한 요청을 일시적으로 거부하여 가용성을 희생한다.8
• Cassandra는 AP 시스템이다. ’모든 노드는 동등하다’는 링(ring) 아키텍처와 최종 일관성(Eventual Consistency) 모델을 기반으로 한다. 네트워크 파티션이 발생하더라도, 클라이언트는 연결 가능한 노드에 쓰기 요청을 할 수 있으며, 시스템은 이 요청을 받아들인다. 파티션이 해결된 후, 노드들은 서로 데이터를 동기화하여 최종적으로 일관된 상태에 도달한다. 이 과정에서 일시적으로 오래된 데이터를 읽거나 데이터 충돌이 발생할 수 있다. Cassandra는 튜닝 가능한 일관성(tunable consistency)을 제공하여, 각 읽기/쓰기 연산마다 요구되는 복제본의 응답 수를 조절할 수 있게 해준다.83
• 트랜잭션 지원:
• CockroachDB는 여러 행과 테이블에 걸친 복잡한 작업을 원자적으로 처리하는 완전한 분산 ACID 트랜잭션을, 기본적으로 가장 강력한 SERIALIZABLE 격리 수준으로 지원한다.85
• Cassandra는 여러 파티션에 걸친 ACID 트랜잭션을 지원하지 않는다. 단일 파티션 내에서 조건부 업데이트를 가능하게 하는 경량 트랜잭션(Lightweight Transactions, LWT)을 제공하지만, 이는 성능 비용이 크고 제한적으로 사용된다.83
• 데이터 모델 및 쿼리 언어:
• CockroachDB는 전통적인 관계형 데이터 모델을 따르며, 정규화된 스키마와 외래 키를 지원한다. 표준 SQL을 사용하여 복잡한 조인, 서브쿼리, 집계 함수를 포함한 강력한 쿼리를 실행할 수 있다.86
• Cassandra는 비정규화를 권장하는 와이드 컬럼 데이터 모델을 사용한다. SQL과 유사한 CQL(Cassandra Query Language)을 제공하지만, 조인이나 서브쿼리를 지원하지 않는다. 따라서 데이터 모델링 단계에서 예상되는 쿼리 패턴을 미리 예측하여 테이블을 설계해야 하는 ‘쿼리 우선’ 접근 방식이 필요하다.83
• 적합한 사용 사례:
• CockroachDB는 데이터의 정확성과 일관성이 비즈니스의 핵심 요구사항인 시스템에 적합하다. 대표적으로 금융 거래 시스템, 전자상거래의 주문 및 재고 관리, 신원 및 접근 관리(IAM) 시스템 등이 있다.83
• Cassandra는 극도의 쓰기 처리량과 상시 가용성이 데이터의 즉각적인 일관성보다 중요한 시스템에 적합하다. 대표적으로 IoT 센서 데이터 수집, 대규모 로깅 및 원격 측정, 소셜 미디어의 활동 피드, 시계열 데이터 저장 등이 있다.84

8.2 vs. Google Spanner: 아키텍처 철학 및 TrueTime 의존성 차이

CockroachDB는 Google Spanner로부터 깊은 영감을 받았지만, 근본적인 아키텍처 철학과 구현 방식에서 중요한 차이점을 보인다. 이 차이는 두 데이터베이스의 배포 유연성과 시장 전략을 결정짓는 핵심 요소이다.

• 시간 동기화와 일관성:
• Spanner의 가장 독창적인 특징은 TrueTime API이다. 이는 데이터센터에 설치된 GPS 수신기와 원자 시계를 사용하여 전 지구적으로 동기화된 시간을 제공하는 시스템이다. TrueTime은 특정 시각 t에 대한 타임스탬프를 요청하면, 실제 절대 시각이 포함될 것이 확실한 시간 간격 [earliest, latest]를 반환한다. 이 간격의 폭이 수 밀리초에 불과할 정도로 매우 좁기 때문에, Spanner는 서로 다른 트랜잭션의 타임스탬프 순서가 실제 발생 순서와 일치함을 보장하는 외부 일관성(External Consistency) 또는 선형성(Linearizability)을 달성할 수 있다.87
• CockroachDB는 이러한 특수 하드웨어 없이 범용 서버에서 동작해야 하므로, NTP에 의존하는 **하이브리드 논리 시계(HLC)**를 사용한다. HLC는 노드 간 최대 시계 오차(max_offset, 기본 500ms)를 가정하고 동작한다. 이로 인해 Spanner와 같은 외부 일관성을 보장하지는 못한다. 즉, 인과 관계가 없는 두 트랜잭션이 서로 다른 노드에서 거의 동시에 발생했을 때, 외부 관찰자가 인지한 순서와 데이터베이스가 할당한 타임스탬프 순서가 다를 수 있다. 그러나 동일한 데이터에 접근하는 등 인과 관계가 있는 트랜잭션에 대해서는 일관된 순서를 보장한다.87
• 배포 유연성:
• Spanner의 TrueTime API 의존성은 Spanner가 Google의 통제된 하드웨어 인프라, 즉 GCP 내에서만 배포될 수 있음을 의미한다. 이는 벤더 종속성을 야기한다.17
• CockroachDB는 HLC를 채택함으로써 하드웨어 독립성을 확보했다. 그 결과, AWS, Azure, GCP 등 모든 퍼블릭 클라우드, 온프레미스 데이터센터, 그리고 이들을 혼합한 하이브리드/멀티 클라우드 환경에 자유롭게 배포할 수 있다. 이는 CockroachDB의 가장 큰 전략적 장점 중 하나이다.17
• 기타 차이점:
• 데이터 지역성 제어: CockroachDB는 SQL DDL을 통해 테이블의 행 단위까지 데이터의 물리적 위치를 정교하게 제어할 수 있는 기능을 제공하여, 데이터 주권 및 지연 시간 최적화에 더 많은 유연성을 제공한다고 주장한다.17
• 쿠버네티스 통합: CockroachDB는 하드웨어 독립성 덕분에 어떤 쿠버네티스 클러스터에도 쉽게 배포할 수 있으며, Anthos나 OpenShift와 같은 멀티 클라우드 쿠버네티스 플랫폼과도 잘 통합된다.17
• SQL 호환성: CockroachDB는 PostgreSQL과의 높은 호환성을 강점으로 내세우는 반면, Spanner는 자체적인 SQL 방언을 사용했으나 최근 PostgreSQL 호환성을 강화하고 있다.17

8.3 vs. TiDB: 아키텍처, 호환성, 생태계 비교

TiDB는 CockroachDB와 함께 분산 SQL 시장을 이끄는 주요 경쟁자 중 하나이다. 두 시스템은 유사한 목표를 추구하지만, 서로 다른 기술적 선택과 생태계 전략을 가지고 있다.

• 아키텍처:
• CockroachDB는 SQL 처리 계층과 데이터 저장 계층이 하나의 바이너리에 통합된 모놀리식(monolithic) 아키텍처를 가지고 있다. 모든 노드가 동일한 역할을 수행하는 대칭적 구조이다.88
• TiDB는 컴퓨팅과 스토리지가 분리된 모듈식(modular) 아키텍처를 채택하고 있다. 상태 비저장(stateless) SQL 처리 계층인 ’TiDB 서버’와 분산 Key-Value 스토리지 계층인 ‘TiKV 서버’, 그리고 클러스터 메타데이터를 관리하는 ’Placement Driver(PD)’로 구성된다. 이러한 분리 덕분에, 컴퓨팅 자원과 스토리지 자원을 독립적으로 확장할 수 있는 유연성을 가진다.89
• 호환성:
• CockroachDB는 PostgreSQL 와이어 프로토콜 및 SQL 구문과 호환된다.90
• TiDB는 MySQL 와이어 프로토콜 및 SQL 구문과 호환된다.89
• 이 차이는 기존에 어떤 데이터베이스 생태계에 익숙하고, 어떤 도구와 라이브러리를 사용하고 있는지에 따라 기술 선택에 매우 중요한 영향을 미친다.
• 트랜잭션 모델:
• CockroachDB는 HLC를 사용하여 트랜잭션 타임스탬프를 분산된 방식으로 생성한다.89
• TiDB는 Google의 Percolator 트랜잭션 모델에 기반하며, 중앙 집중화된 Placement Driver(PD)로부터 모든 트랜잭션이 타임스탬프를 할당받는다.89
• 워크로드 지원:
• CockroachDB는 전통적으로 빠른 응답 시간이 중요한 OLTP(Online Transaction Processing) 워크로드에 집중해왔다.
• TiDB는 ’TiFlash’라는 컬럼 기반 스토리지 엔진을 추가하여, 단일 시스템 내에서 OLTP와 OLAP(Online Analytical Processing) 워크로드를 동시에 처리할 수 있는 HTAP(Hybrid Transactional/Analytical Processing) 데이터베이스임을 강조한다. 이를 통해 별도의 데이터 웨어하우스로 데이터를 ETL(Extract, Transform, Load)하는 과정 없이 실시간 분석이 가능하다고 주장한다.89

8.3.1 테이블 4: 분산 데이터베이스 시스템 비교

9. 산업별 적용 사례 및 워크로드 분석

CockroachDB의 아키텍처적 강점은 다양한 산업 분야에서 발생하는 실제적인 문제들을 해결하는 데 효과적으로 적용된다. 특히 강력한 일관성, 높은 가용성, 그리고 지리적 확장성이 동시에 요구되는 미션 크리티컬 워크로드에서 그 가치가 두드러진다.

9.1 금융 서비스: 결제 시스템, 계좌 원장

금융 서비스 산업은 데이터베이스에 가장 엄격한 요구사항을 부과하는 분야 중 하나이다. 결제 처리, 계좌 원장 관리, 거래 시스템 등은 단 한 건의 오류나 데이터 불일치도 허용되지 않으며, 24시간 365일 중단 없는 서비스가 필수적이다.

• 핵심 요구사항:
• 데이터 정확성: 이중 지급이나 잘못된 계좌 잔고와 같은 오류를 방지하기 위해 모든 트랜잭션은 원자적으로 처리되어야 하며, 데이터는 항상 일관된 상태를 유지해야 한다. 이는 분산 환경에서도 보장되어야 한다.91
• 상시 가용성: 시스템 장애나 정기적인 유지보수로 인한 서비스 중단은 막대한 금전적 손실과 고객 신뢰도 하락으로 이어진다. 제로 다운타임(zero downtime)이 목표이다.91
• 규정 준수: 금융 데이터는 GDPR, PCI DSS 등 엄격한 데이터 보호 및 주권 규제의 대상이 된다. 데이터의 물리적 저장 위치를 제어할 수 있어야 한다.93
• CockroachDB의 해결책:
• 전통적인 RDBMS인 PostgreSQL을 사용하는 경우, 고가용성을 위해 액티브-패시브 구조를 사용해야 하며 이는 장애 조치 시 다운타임을 유발하고, 유지보수 및 업그레이드를 위해서도 계획된 다운타임이 필요하다. 또한, 단일 쓰기 노드(single writer node) 구조는 글로벌 확장 시 병목 현상을 야기한다.91
• CockroachDB는 기본적으로 제공하는 SERIALIZABLE 격리 수준의 분산 ACID 트랜잭션을 통해 여러 데이터센터에 걸쳐서도 데이터의 정확성과 일관성을 보장한다.93
• 다중 활성(multi-active) 아키텍처와 자동 장애 복구 기능은 노드, 데이터센터, 심지어 리전 장애 시에도 서비스 중단 없이 운영을 지속하게 해준다. 롤링 업그레이드 기능은 계획된 유지보수 중에도 다운타임을 제거한다.91
• 지오-파티셔닝(Geo-partitioning) 기능을 사용하여 고객 데이터를 특정 국가나 지역에 고정시킴으로써 데이터 주권 규정을 준수하고, 동시에 해당 지역 고객에게 낮은 지연 시간의 서비스를 제공할 수 있다.93
• 적용 사례: 다수의 Fortune 50대 은행을 포함한 여러 금융 기관들이 내부 개발자를 위한 DBaaS(Database-as-a-Service) 플랫폼의 일부로 CockroachDB를 제공하거나, 글로벌 결제 시스템의 백엔드로 활용하고 있다.91 한 금융 서비스 고객은 CockroachDB의 복원력을 테스트하기 위해 로컬 머신에서 클러스터를 구성하고 의도적으로 노드를 종료시키는 등 파괴적인 테스트를 수행했지만 시스템을 다운시킬 수 없었다고 증언하며 그 견고함을 높이 평가했다.93

10. 참고 자료

1. Distributed SQL - CockroachDB, https://www.cockroachlabs.com/glossary/distributed-db/distributed-sql/
2. What is distributed SQL? The evolution of the database - CockroachDB, https://www.cockroachlabs.com/blog/what-is-distributed-sql/
3. CockroachDB | Distributed SQL for always-on customer experiences, https://www.cockroachlabs.com/
4. Vertical vs. horizontal scaling: What’s the difference and which is better? - CockroachDB, https://www.cockroachlabs.com/blog/vertical-scaling-vs-horizontal-scaling/
5. CockroachDB - The Definitive Guide, https://downloads.ctfassets.net/00voh0j35590/6GTPaSbJrQzSRBYxP18HSW/82139976fc80920b3914f0cb494ae80d/oreilly-cockroachdb-the-definitive-guide.pdf
6. Mainframe to Distributed SQL, Part 3: Distributed Database Architecture - CockroachDB, https://www.cockroachlabs.com/blog/distributed-database-architecture/
7. CockroachDB — the cloud native, distributed SQL database designed for high availability, effortless scale, and control over data placement. - GitHub, https://github.com/cockroachdb/cockroach
8. CockroachDB FAQs, https://www.cockroachlabs.com/docs/stable/frequently-asked-questions
9. The new stack: Meet CockroachDB, the resilient SQL database, https://www.cockroachlabs.com/blog/the-new-stack-meet-cockroachdb-the-resilient-sql-database/
10. CockroachDB - CelerData, https://celerdata.com/glossary/cockroachdb
11. Company + Culture - CockroachDB, https://www.cockroachlabs.com/blogs/culture/
12. The Resilient Geo-Distributed SQL Database (SIGMOD 2020) - CockroachDB, https://www.cockroachlabs.com/guides/cockroachdb-the-resilient-geo-distributed-sql-database-sigmod-2020/
13. Why CockroachDB?, https://www.cockroachlabs.com/docs/stable/why-cockroachdb
14. Architectural Simplification - CockroachDB, https://www.cockroachlabs.com/architectural-simplification/
15. Comparing CockroachDB and PostgreSQL, https://www.cockroachlabs.com/blog/postgresql-vs-cockroachdb/
16. Hybrid Logical Clock (HLC) Timestamps - CockroachDB, https://www.cockroachlabs.com/glossary/distributed-db/hybrid-logical-clock-hlc-timestamps/
17. 4 architectural differences between Spanner & CockroachDB, https://www.cockroachlabs.com/blog/spanner-vs-cockroachdb/
18. Compare CockroachDB and Google Spanner | Cockroach Labs, https://www.cockroachlabs.com/compare/cockroachdb-vs-google-spanner/
19. Compare CockroachDB and Google Spanner | Cockroach Labs, https://www.cockroachlabs.com/lp/compare/cockroachdb-vs-google-spanner/
20. CockroachDB: The Resilient Geo-Distributed SQL Database - Murat Demirbas, http://muratbuffalo.blogspot.com/2022/03/cockroachdb-resilient-geo-distributed.html
21. Intro to multi-region distributed SQL topologies - CockroachDB, https://www.cockroachlabs.com/blog/multi-region-topology-patterns/
22. Distributed SQL (NewSQL) Made Easy: How CockroachDB …, https://www.cockroachlabs.com/blog/automated-rebalance-and-repair/
23. Architecture Overview - CockroachDB, https://www.cockroachlabs.com/docs/stable/architecture/overview
24. Architecture Overview - CockroachDB, https://www.cockroachlabs.com/docs/stable/architecture/overview.html
25. CockroachDB: The Resilient Geo-Distributed SQL Database - Reliable Computer Systems, https://rcs.uwaterloo.ca/~ali/cs854-f23/papers/cockroachdb.pdf
26. The Resilience of CockroachDB: A Distributed SQL Database Built to Survive | by Sanjeev Singh | Medium, https://medium.com/@sjksingh/the-resilience-of-cockroachdb-a-distributed-sql-database-built-to-survive-3e9160f6ae20
27. Clock Management in CockroachDB: Good Timekeeping is Key, https://www.cockroachlabs.com/blog/clock-management-cockroachdb/
28. Life of a Distributed Transaction - CockroachDB, https://www.cockroachlabs.com/docs/stable/architecture/life-of-a-distributed-transaction
29. Serializable, lockless, distributed: Isolation in CockroachDB, https://www.cockroachlabs.com/blog/serializable-lockless-distributed-isolation-cockroachdb/
30. Developer Basics - CockroachDB, https://www.cockroachlabs.com/docs/stable/developer-basics
31. Transactions - CockroachDB, https://www.cockroachlabs.com/docs/stable/transactions
32. What is ACID? Atomicity, Consistency, Isolation, Durability - CockroachDB, https://www.cockroachlabs.com/glossary/distributed-db/acid-database/
33. Parallel Commits: An atomic commit protocol for globally distributed …, https://www.cockroachlabs.com/blog/parallel-commits/
34. Serializable Transactions - CockroachDB, https://www.cockroachlabs.com/docs/stable/demo-serializable
35. Cockroach University: ACID Transactions - YouTube, https://www.youtube.com/watch?v=M6zbQ5_sgq8
36. No Dirty Reads: Everything you always wanted to know about SQL isolation levels (but were too afraid to ask) - CockroachDB, https://www.cockroachlabs.com/blog/sql-isolation-levels-explained/
37. The Design & Architecture of CockroachDB Beta - YouTube, https://www.youtube.com/watch?v=p8aJuk7TJJA
38. What to do when a transaction fails in CockroachDB, https://www.cockroachlabs.com/blog/what-to-do-when-a-transaction-fails-in-cockroachdb/
39. FOR UPDATE and FOR SHARE - CockroachDB, https://www.cockroachlabs.com/docs/stable/select-for-update
40. Transaction Layer - CockroachDB, https://www.cockroachlabs.com/docs/stable/architecture/transaction-layer
41. All Things Clock, Time and Order in Distributed Systems: Hybrid Logical Clock in Depth | by Kousik Nath | Geek Culture | Medium, https://medium.com/geekculture/all-things-clock-time-and-order-in-distributed-systems-hybrid-logical-clock-in-depth-7c645eb03682
42. Transaction Layer - CockroachDB, https://www.cockroachlabs.com/docs/stable/architecture/transaction-layer.html
43. Logical Physical Clocks - Department of Computer Science and Engineering, http://www.cse.buffalo.edu/~demirbas/publications/hlc.pdf
44. An Enterprise Architecture Overview - CockroachDB, https://www.cockroachlabs.com/blog/cockroachdb-enterprise-architecture/
45. Product Overview | Enable modern, resilient applications with CockroachDB, https://www.cockroachlabs.com/product/overview/
46. Surviving 11 Application and Database Failures with CockroachDB, https://www.cockroachlabs.com/blog/surviving-application-database-failures/
47. Replication Layer - CockroachDB, https://www.cockroachlabs.com/docs/stable/architecture/replication-layer
48. Get started geo-partitioning data with our command-line CockroachDB demo, https://www.cockroachlabs.com/blog/get-started-geo-partitioning-data-with-our-command-line-cockroachdb-demo/
49. Disaster Recovery Planning - CockroachDB, https://www.cockroachlabs.com/docs/stable/disaster-recovery-planning
50. Upgrade CockroachDB self-hosted, https://www.cockroachlabs.com/docs/stable/upgrade-cockroach-version
51. Table Partitioning - CockroachDB, https://www.cockroachlabs.com/docs/stable/partitioning
52. Table Localities - CockroachDB, https://www.cockroachlabs.com/docs/stable/table-localities
53. How to improve application performance using data location - CockroachDB, https://www.cockroachlabs.com/blog/geo-partitioning/
54. Data Partitioning by Location - Geo-Partitioning | Cockroach Labs, https://www.cockroachlabs.com/product/geo-partitioning/
55. Why CockroachDB and PostgreSQL are compatible, https://www.cockroachlabs.com/blog/why-postgres/
56. “PostgreSQL Compatible Databases”: A Tale of Two Approaches - CockroachDB, https://www.cockroachlabs.com/blog/postgresql-compatible-database-cockroachdb/
57. PostgreSQL Compatibility - CockroachDB, https://www.cockroachlabs.com/docs/stable/postgresql-compatibility
58. SQL Feature Support in CockroachDB, https://www.cockroachlabs.com/docs/stable/sql-feature-support
59. PostgreSQL data types: what are they, and when to use each - CockroachDB, https://www.cockroachlabs.com/blog/postgres-data-types/
60. sql: make the CockroachDB integer types more compatible with postgres #26925 - GitHub, https://github.com/cockroachdb/cockroach/issues/26925
61. CockroachDB Vs. PostgreSQL - Key Differences - Airbyte, https://airbyte.com/data-engineering-resources/cockroachdb-vs-postgres
62. pg_catalog - CockroachDB, https://www.cockroachlabs.com/docs/stable/pg-catalog
63. CockroachDB Compatibility | Hasura GraphQL Docs, https://hasura.io/docs/2.0/databases/postgres/cockroachdb/hasura-cockroachdb-compatibility/
64. Third-Party Tools Supported by Cockroach Labs - CockroachDB, https://www.cockroachlabs.com/docs/stable/third-party-database-tools
65. Install a Driver or ORM Framework - CockroachDB, https://www.cockroachlabs.com/docs/stable/install-client-drivers
66. 8 cool third-party GUI tools for Postgres-compliant databases - CockroachDB, https://www.cockroachlabs.com/blog/cockroachdb-gui-options/
67. A PostgreSQL Interface for CockroachDB Data using the CData ODBC Driver, https://www.cdata.com/kb/tech/cockroachdb-odbc-postgresql-fdw.rst
68. Build a PostgreSQL Interface for CockroachDB Data using the CData JDBC Driver, https://www.cdata.com/kb/tech/cockroachdb-jdbc-postgresql-fdw.rst
69. MOLT Schema Conversion Tool - CockroachDB, https://www.cockroachlabs.com/docs/cockroachcloud/migrations-page
70. MOLT Verify: Ensuring Data Integrity in Database Migrations, https://www.cockroachlabs.com/blog/data-integrity-molt-verify-migrations/
71. Architecture of a Serverless Database, https://assets.ctfassets.net/00voh0j35590/6FswAaw2GUVwnRWNHWmvHM/416089a7edf4a46c281d837a9042f33d/cockroach-labs-architecture-of-a-serverless-database.pdf
72. How we built a serverless SQL database - CockroachDB, https://www.cockroachlabs.com/blog/how-we-built-cockroachdb-serverless/
73. Production Checklist - CockroachDB, https://www.cockroachlabs.com/docs/stable/recommended-production-settings
74. CockroachDB on Kubernetes | Cockroach Labs, https://www.cockroachlabs.com/product/kubernetes/
75. Choose a Deployment Option - CockroachDB, https://www.cockroachlabs.com/docs/stable/choose-a-deployment-option
76. CockroachDB Pricing | Cockroach Labs, https://www.cockroachlabs.com/pricing/
77. CockroachDB Pricing Guide: Cost Analysis for Database Engineers - Airbyte, https://airbyte.com/data-engineering-resources/cockroachdb-pricing
78. Orchestrate CockroachDB Across Multiple Kubernetes Clusters, https://www.cockroachlabs.com/docs/stable/orchestrate-cockroachdb-with-kubernetes-multi-cluster
79. Deploy a Local Cluster from Binary (Secure) - CockroachDB, https://www.cockroachlabs.com/docs/stable/secure-a-cluster
80. Deploy CockroachDB On-Premises, https://www.cockroachlabs.com/docs/stable/deploy-cockroachdb-on-premises
81. Essential Metrics for CockroachDB Self-Hosted Deployments, https://www.cockroachlabs.com/docs/stable/essential-metrics-self-hosted
82. A PostgresSQL managed service…but better? - CockroachDB, https://www.cockroachlabs.com/compare/cockroachdb-vs-postgresql/
83. CockroachDB vs Apache Cassandra: Choosing the Right …, https://hackernoon.com/cockroachdb-vs-apache-cassandra-choosing-the-right-distributed-database-for-your-use-case
84. CockroachDB vs Cassandra: The Ultimate Guide to Choosing Your Distributed Database | by Harshith Gowda | Jul, 2025 | Medium, https://medium.com/@harshithgowdakt/cockroachdb-vs-cassandra-the-ultimate-guide-to-choosing-your-distributed-database-1d2ada695bb9
85. Matchups: CockroachDB vs Cassandra | Databases Comparison, https://swiftorial.com/matchups/databases/cockroachdb-vs-cassandra/
86. Why CockroachDB and Apache Cassandra? | Cockroach Labs, https://www.cockroachlabs.com/compare/cassandra-vs-cockroachdb/
87. The One Crucial Difference Between Spanner and CockroachDB | AuthZed.com, https://authzed.com/blog/prevent-newenemy-cockroachdb
88. CockroachDB / TiDB - Reddit, https://www.reddit.com/r/CockroachDB/comments/1814ucl/cockroachdb_tidb/
89. What are the advantage of CockroackDB over TiDB/TiKV? - Quora, https://www.quora.com/What-are-the-advantage-of-CockroackDB-over-TiDB-TiKV
90. TiDB vs. CockroachDB: the Distributed Clash between MySQL and …, https://www.bytebase.com/blog/tidb-vs-cockroachdb/
91. Top 5 financial services use cases for CockroachDB, https://www.cockroachlabs.com/blog/top-5-financial-services-use-cases-for-cockroachdb/
92. CockroachDB for Banking & Wallet Services | Use Case Overview, https://www.cockroachlabs.com/solutions/usecases/banking-and-wallet/
93. Financial Services - Cockroach Labs, https://www.cockroachlabs.com/solutions/verticals/financialservices/
94. CockroachDB for Finserv, https://assets.ctfassets.net/00voh0j35590/3ycXpXkhzWGpyLI3OS746j/f529bce6955068cd6a726a26d0c14b49/CockroachDB-for-Finserv_October2022.pdf
95. Trusted by Enterprises | Customer Success with CockroachDB, https://www.cockroachlabs.com/customers/